diff options
author | Justin Hibbits <jhibbits@FreeBSD.org> | 2016-03-18 01:28:41 +0000 |
---|---|---|
committer | Justin Hibbits <jhibbits@FreeBSD.org> | 2016-03-18 01:28:41 +0000 |
commit | da1b038af9f9551a0b2f33d312b4eede00aa1542 (patch) | |
tree | 79d2db0783ae236486e47ff49d1e85214325a9e0 /sys/dev/mxge | |
parent | 7b54043f1718af1af1549296b25d0803f72799cf (diff) | |
download | src-da1b038af9f9551a0b2f33d312b4eede00aa1542.tar.gz src-da1b038af9f9551a0b2f33d312b4eede00aa1542.zip |
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
Notes
Notes:
svn path=/head/; revision=297000
Diffstat (limited to 'sys/dev/mxge')
-rw-r--r-- | sys/dev/mxge/if_mxge.c | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/sys/dev/mxge/if_mxge.c b/sys/dev/mxge/if_mxge.c index 928917f9cf8f..ddbaf89c8230 100644 --- a/sys/dev/mxge/if_mxge.c +++ b/sys/dev/mxge/if_mxge.c @@ -4612,7 +4612,7 @@ mxge_add_msix_irqs(mxge_softc_t *sc) device_printf(sc->dev, "using %d msix IRQs:", sc->num_slices); for (i = 0; i < sc->num_slices; i++) - printf(" %ld", rman_get_start(sc->msix_irq_res[i])); + printf(" %jd", rman_get_start(sc->msix_irq_res[i])); printf("\n"); } return (0); @@ -4668,7 +4668,7 @@ mxge_add_single_irq(mxge_softc_t *sc) return ENXIO; } if (mxge_verbose) - device_printf(sc->dev, "using %s irq %ld\n", + device_printf(sc->dev, "using %s irq %jd\n", sc->legacy_irq ? "INTx" : "MSI", rman_get_start(sc->irq_res)); err = bus_setup_intr(sc->dev, sc->irq_res, @@ -4823,7 +4823,7 @@ mxge_attach(device_t dev) sc->sram = rman_get_virtual(sc->mem_res); sc->sram_size = 2*1024*1024 - (2*(48*1024)+(32*1024)) - 0x100; if (sc->sram_size > rman_get_size(sc->mem_res)) { - device_printf(dev, "impossible memory region size %ld\n", + device_printf(dev, "impossible memory region size %jd\n", rman_get_size(sc->mem_res)); err = ENXIO; goto abort_with_mem_res; |