src-test2/sys/dev/proto, branch release/11.0.0 FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F11.0.0 2016-03-18T01:28:41Z Use uintmax_t (typedef'd to rman_res_t type) for rman ranges. 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 Check the sync operation. 2015-07-28T04:54:05Z Marcel Moolenaar marcel@FreeBSD.org 2015-07-28T04:54:05Z urn:sha1:f40c76d8dedcc7cf095b00787567a4f1d575280f o make sure the boundary is a power of 2, when not zero. 2015-07-26T16:39:37Z Marcel Moolenaar marcel@FreeBSD.org 2015-07-26T16:39:37Z urn:sha1:b2ce196ca1af146f5aa010a519d79705c72137bb o don't convert 0 to ~0 just so that we can use MIN. ~0 is not a valid boundary. Introduce BNDRY_MIN that deals with 0 values that mean no boundary. Check the hw.proto.attach environment variable for devices that 2015-07-19T23:37:45Z Marcel Moolenaar marcel@FreeBSD.org 2015-07-19T23:37:45Z urn:sha1:be00e098188c0dec135fb449334593731abc0033 proto(4) should attach to instead of the normal driver. Document the variable. Implement unload and sync operations. 2015-07-03T05:44:58Z Marcel Moolenaar marcel@FreeBSD.org 2015-07-03T05:44:58Z urn:sha1:42d3ab5d1b225b1783288c830ae25d67a4f34aea Add create, destroy and load of memory descriptors. 2015-07-03T01:52:22Z Marcel Moolenaar marcel@FreeBSD.org 2015-07-03T01:52:22Z urn:sha1:89abdea8f020e3afd03227c7fa2d3ec20cb26689 Add an ISA/ACPI bus attachment to proto(4). 2015-07-02T19:21:29Z Marcel Moolenaar marcel@FreeBSD.org 2015-07-02T19:21:29Z urn:sha1:3a232946f745ad78e2257711fc757da9e0aa20af Change the probe to what was intended: attach to devices with 2015-06-22T00:34:29Z Marcel Moolenaar marcel@FreeBSD.org 2015-06-22T00:34:29Z urn:sha1:3f745144d99d23b4819d3ce255ff333e8ee51c6f a type 0 header and not to function 0 devices. We need to handle 64-bit BARs ourselves to avoid that the 2015-06-12T12:27:10Z Marcel Moolenaar marcel@FreeBSD.org 2015-06-12T12:27:10Z urn:sha1:00f73819c209d0442ba7134b457a8b4a5eed2686 PCI infrastructure instantiates a non-existent resource. This has BARs suddenly show up with pciconf(8) under VMware as well. Now that we read the BAR ourselves, ask for the correct resource type. Load the allocated memory and return both the physical 2015-06-10T22:33:56Z Marcel Moolenaar marcel@FreeBSD.org 2015-06-10T22:33:56Z urn:sha1:90a1793cce2199c0744ba996c4d8638cceebb165 address and the bus address to the application.