Devices with 36-bit paddr on 32-bit system

[Bruce Evans]

On Sun, 30 Aug 2015, Bruce Evans wrote:

> % ...
> % Index: sys/sys/bus.h
> % ===================================================================
> % --- sys/sys/bus.h	(revision 287189)
> % +++ sys/sys/bus.h	(working copy)
> % @@ -29,6 +29,7 @@
> %  #ifndef _SYS_BUS_H_
> %  #define _SYS_BUS_H_
> % % +#include <machine/_bus.h>
> %  #include <machine/_limits.h>
> %  #include <sys/_bus_dma.h>
> %  #include <sys/ioccom.h>
> % @@ -292,8 +293,8 @@
> %  	int	rid;			/**< @brief resource identifier */
> %  	int	flags;			/**< @brief resource flags */
> %  	struct	resource *res;		/**< @brief the real resource when 
> allocated */
> % -	u_long	start;			/**< @brief start of resource range 
> */
> % -	u_long	end;			/**< @brief end of resource range */
> % +	bus_addr_t	start;		/**< @brief start of resource range 
> */
> % +	bus_addr_t	end;		/**< @brief end of resource range */

Mail programs (mostly mine) corrupted the formatting more competely.

> I think rman functions should use an rman type and not hard-code bus_addr_t.
> Related bus functions should then use this type.  Style bugs from blind
> substitution can be reduced by using a less verbose name.
>
> %  	u_long	count;			/**< @brief count within range */
> %  };

Or just use uintmax_t for everything in rman.  rman was written before
C99 broke C by making u_long no longer the largest integer type.  It
used u_long because it was the largest integer type (though it actually
wasn't, since FreeBSD used nonstandard extensions in Gnu C) and it is
easiest to use a single non-typedefed type that is large enough for all
cases.  uintmax_t is C99's replacement of u_long.

I don't like the bloat from using uintmax_t for everything, but rman
should only used for initialization so uintmax_t for rman should only
give space bloat, only on 32-bit arches.

An rman typedef for this type allows re-optimizing the 32-bit arches,
but brings back the problem of typedefed types being hard to use.

Bruce