FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F11.0.0 2016-04-21T15:38:28Z 2016-04-21T15:38:28Z Pedro F. Giffuni pfg@FreeBSD.org 2016-04-21T15:38:28Z urn:sha1:8dfea46460a0befc49458e87d2078a5ca100e0eb Suggested by: jhb 2016-03-28T20:16:29Z Warner Losh imp@FreeBSD.org 2016-03-28T20:16:29Z urn:sha1:cb49b6548156943031d9f343bae1b83f07fe0f9c devctl_safe_quote() so it can be used more generally. 2016-03-18T01:28:41Z Justin Hibbits jhibbits@FreeBSD.org 2016-03-18T01:28:41Z urn:sha1:da1b038af9f9551a0b2f33d312b4eede00aa1542 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-03T05:07:35Z Justin Hibbits jhibbits@FreeBSD.org 2016-03-03T05:07:35Z urn:sha1:534ccd7bbfadde557eeffe986e5462455c8111ea Summary: The idea behind this is '~0ul' is well-defined, and casting to uintmax_t, on a 32-bit platform, will leave the upper 32 bits as 0. The maximum range of a resource is 0xFFF.... (all bits of the full type set). By dropping the 'ul' suffix, C type promotion rules apply, and the sign extension of ~0 on 32 bit platforms gets it to a type-independent 'unsigned max'. Reviewed By: cem Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5255 2016-02-27T03:38:01Z Justin Hibbits jhibbits@FreeBSD.org 2016-02-27T03:38:01Z urn:sha1:c47476d7e6801deffc8b3c057d0fbf7d2335a0c2 Most calls to bus_alloc_resource() use "anywhere" as the range, with a given count. Migrate these to use the new bus_alloc_resource_anywhere() API. Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D5370 2016-02-20T01:32:58Z Justin Hibbits jhibbits@FreeBSD.org 2016-02-20T01:32:58Z urn:sha1:7915adb56014e31e8ed8a4418060625c2e223fc0 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 2016-01-27T02:23:54Z Justin Hibbits jhibbits@FreeBSD.org 2016-01-27T02:23:54Z urn:sha1:2dd1bdf1834c53d048d3d9a7079b45afea5cecd7 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 2015-12-11T05:27:56Z Warner Losh imp@FreeBSD.org 2015-12-11T05:27:56Z urn:sha1:f6cea53f9db2d88883ea7d7cee5fac10e186650b block. Use it in all the PNP drivers to export either the current PNP table. For uart, create a custom table and export it using MODULE_PNP_INFO since it's the only one that matches on function number. Differential Review: https://reviews.freebsd.org/D3461 2014-12-03T00:47:05Z Warner Losh imp@FreeBSD.org 2014-12-03T00:47:05Z urn:sha1:86fd88736fe7b4044ee31715dca3b25ffd7f2435 Always include the card human readable name. We support ~270 cards and at ~20 bytes each, this bloats things by only ~5k. Retain the PCMCIA_CARD vs PCMCIA_CARD_D distinction, though, in case this is intolerable. 2014-11-22T18:40:14Z Warner Losh imp@FreeBSD.org 2014-11-22T18:40:14Z urn:sha1:2f1c4b0c87cd1e4f15e96e641782cbab429e5b08