jhibbits 720f47c9ed Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.
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
2016-03-18 01:28:41 +00:00
..
2016-03-01 17:47:32 +00:00
2016-02-17 21:24:26 +00:00
2016-02-18 01:24:10 +00:00
2016-03-12 09:44:23 +00:00
2016-02-18 01:24:10 +00:00
2016-02-18 01:24:10 +00:00
2016-03-01 17:47:32 +00:00
2015-02-24 01:00:46 +00:00
2015-03-08 19:55:46 +00:00
2016-03-01 17:47:32 +00:00
2016-02-25 04:32:17 +00:00
2015-01-23 15:14:30 +00:00
2015-06-30 17:00:45 +00:00
2015-06-30 17:00:45 +00:00
2015-08-30 08:48:31 +00:00
2016-01-07 21:16:44 +00:00
2016-02-19 01:57:51 +00:00
2016-03-03 19:49:37 +00:00
2016-02-18 01:24:10 +00:00
2015-04-29 20:08:03 +00:00
2016-03-01 17:47:32 +00:00
2016-02-25 02:46:47 +00:00
2016-03-01 17:47:32 +00:00
2016-03-01 17:47:32 +00:00
2015-08-28 02:29:31 +00:00
2016-03-16 16:56:28 +00:00
2014-11-18 21:58:57 +00:00
2016-02-19 18:05:02 +00:00
2016-01-26 22:32:58 +00:00
2016-02-17 21:09:19 +00:00
2015-09-07 21:59:11 +00:00
2016-03-01 17:47:32 +00:00
2016-02-18 03:05:08 +00:00
2015-06-30 17:00:45 +00:00
2016-02-21 18:51:48 +00:00
2015-06-30 17:00:45 +00:00
2016-01-01 17:56:52 +00:00
2016-03-01 17:47:32 +00:00
2016-02-18 01:24:10 +00:00
2015-10-08 17:32:17 +00:00
2014-11-21 21:34:19 +00:00
2015-06-30 17:00:45 +00:00
2016-03-14 07:24:08 +00:00
2016-03-01 17:47:32 +00:00
2016-02-18 01:24:10 +00:00
2016-03-01 17:47:32 +00:00