| Age | Commit message (Collapse) | Author |
|---|
|
machines, only a few 486 machines that used it, and those haven't had
enough memory to run FreeBSD for quite some time (often limited to
16MB).
Not to be confused with the Machine Check Architecture, which is still
very much alive and used (and untouched by this commit).
No Objection From: arch@
Notes:
svn path=/head/; revision=313783
|
|
On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but
type `long' is only 32-bit. This extends rman's resources to uintmax_t. With
this change, any resource can feasibly be placed anywhere in physical memory
(within the constraints of the driver).
Why uintmax_t and not something machine dependent, or uint64_t? Though it's
possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on
32-bit architectures. 64-bit architectures should have plenty of RAM to absorb
the increase on resource sizes if and when this occurs, and the number of
resources on memory-constrained systems should be sufficiently small as to not
pose a drastic overhead. That being said, uintmax_t was chosen for source
clarity. If it's specified as uint64_t, all printf()-like calls would either
need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t
aren't horrible, but it would also bake into the API for
resource_list_print_type() either a hidden assumption that entries get cast to
uintmax_t for printing, or these calls would need the PRI*64 macros. Since
source code is meant to be read more often than written, I chose the clearest
path of simply using uintmax_t.
Tested on a PowerPC p5020-based board, which places all device resources in
0xfxxxxxxxx, and has 8GB RAM.
Regression tested on qemu-system-i386
Regression tested on qemu-system-mips (malta profile)
Tested PAE and devinfo on virtualbox (live CD)
Special thanks to bz for his testing on ARM.
Reviewed By: bz, jhb (previous)
Relnotes: Yes
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D4544
Notes:
svn path=/head/; revision=297000
|
|
This simplifies checking for default resource range for bus_alloc_resource(),
and improves readability.
This is part of, and related to, the migration of rman_res_t from u_long to
uintmax_t.
Discussed with: jhb
Suggested by: marcel
Notes:
svn path=/head/; revision=295832
|
|
Summary:
Migrate to using the semi-opaque type rman_res_t to specify rman resources. For
now, this is still compatible with u_long.
This is step one in migrating rman to use uintmax_t for resources instead of
u_long.
Going forward, this could feasibly be used to specify architecture-specific
definitions of resource ranges, rather than baking a specific integer type into
the API.
This change has been broken out to facilitate MFC'ing drivers back to 10 without
breaking ABI.
Reviewed By: jhb
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5075
Notes:
svn path=/head/; revision=294883
|
|
one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.
Notes:
svn path=/head/; revision=227843
|
|
Reviewed by: imp, current@
Approved by: jhb (mentor)
Notes:
svn path=/head/; revision=194020
|
|
to int rule. See ISO C Standard: SS6.7.5.3:15.
Approved by: kib (mentor)
Reviewed by: warner
Tested by: silence on -current
Notes:
svn path=/head/; revision=189004
|
|
Also some minor style cleanups.
Notes:
svn path=/head/; revision=119418
|
|
Change all in-tree consumers to include <sys/limits.h>
Discussed on: standards@
Partially submitted by: Craig Rodrigues <rodrigc@attbi.com>
Notes:
svn path=/head/; revision=114216
|
|
nexus(4) in the case of machines w/o equivalent bridges on a PCI bus.
Reported by: winter
Pointy hat to: jhb
Notes:
svn path=/head/; revision=104015
|
|
- Return NULL from mca_alloc_resource() instead of ENOENT if we are
passed in an empty resource list.
Notes:
svn path=/head/; revision=71239
|
|
generic resource_list management functions.
I'll deal with the EISA bits later.
Not objected to by: new-bus
Notes:
svn path=/head/; revision=69295
|
|
Notes:
svn path=/head/; revision=57980
|
|
Notes:
svn path=/head/; revision=55890
|
|
device_add_child_ordered(). 'ivars' may now be set using the
device_set_ivars() function.
This makes it easier for us to change how arbitrary data structures are
associated with a device_t. Eventually we won't be modifying device_t
to add additional pointers for ivars, softc data etc.
Despite my best efforts I've probably forgotten something so let me know
if this breaks anything. I've been running with this change for months
and its been quite involved actually isolating all the changes from
the rest of the local changes in my tree.
Reviewed by: peter, dfr
Notes:
svn path=/head/; revision=54073
|
|
first arg.
Reminded by: Andy Farkas <andyf@speednet.com.au>
Notes:
svn path=/head/; revision=52915
|
|
- Work around a problem not yet solved in the tree (but solved in mine.)
device_get_ivars() should never be cast to a struct resource_list *
The solution, under review, involves the creation of a
device_get_resource_list() function. More later.
Notes:
svn path=/head/; revision=52050
|
|
Noticed by: Peter
Notes:
svn path=/head/; revision=51678
|
|
implement the resource management code correctly, using approved
interfaces.
While I'm here, clean up a few things.
Notes:
svn path=/head/; revision=51674
|
|
Should we ever find ourselves on an RS/6000 this code should work
with few changes.
Notes:
svn path=/head/; revision=50825
|
