src-test2/sys/dev/mca, branch release/11.4.0

Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.

2016-03-18T01:28:41Z

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

Introduce a RMAN_IS_DEFAULT_RANGE() macro, and use it.

2016-02-20T01:32:58Z

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

Convert rman to use rman_res_t instead of u_long

2016-01-27T02:23:54Z

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

- There's no need to overwrite the default device method with the default

2011-11-22T21:28:20Z

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.

strict kobj signatures: fix assortment of bus_read_ivar impls

2009-06-11T17:06:58Z

Reviewed by: imp, current@ Approved by: jhb (mentor)

Change the functions to ANSI in those cases where it breaks promotion

2009-02-24T18:09:31Z

to int rule. See ISO C Standard: SS6.7.5.3:15. Approved by: kib (mentor) Reviewed by: warner Tested by: silence on -current

Use __FBSDID().

2003-08-24T17:55:58Z

Also some minor style cleanups.

Deprecate machine/limits.h in favor of new sys/limits.h.

2003-04-29T13:36:06Z

Change all in-tree consumers to include Discussed on: standards@ Partially submitted by: Craig Rodrigues

Argh, isa(4), eisa(4) and mca(4) now attach to legacy(4) instead of

2002-09-26T18:40:06Z

nexus(4) in the case of machines w/o equivalent bridges on a PCI bus. Reported by: winter Pointy hat to: jhb

- Remove an unused write_ivars function that didn't do anything anyway.

2001-01-19T09:29:34Z

- Return NULL from mca_alloc_resource() instead of ENOENT if we are passed in an empty resource list.