FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F11.3.0 2018-04-24T16:45:13Z 2018-04-24T16:45:13Z Ian Lepore ian@FreeBSD.org 2018-04-24T16:45:13Z urn:sha1:b4e235847c1c66648adc45a692a14c62c98794c2 driver no longer exists in head, so this is a direct commit to 11-stable. 2018-04-09T16:18:02Z Brooks Davis brooks@FreeBSD.org 2018-04-09T16:18:02Z urn:sha1:59d5ad73adaba225faf4e4bae3cb72ff7bd42b0a I missed that this was an assignment (a bad pattern, use another member) on i386. As wl(4) is i386 only and gone in head, just expand the ifr_ifru member rather than adding an accessor. Reported by: gjb 2018-04-08T16:54:07Z Brooks Davis brooks@FreeBSD.org 2018-04-08T16:54:07Z urn:sha1:be53904b8dac7d13270889f581d6d3b29d365dc7 Use an accessor function to access ifr_data. This fixes 32-bit compat (no ioctl command defintions are required as struct ifreq is the same size). Reviewed by: kib Obtained from: CheriBSD Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D14900 2017-07-12T20:10:53Z John Baldwin jhb@FreeBSD.org 2017-07-12T20:10:53Z urn:sha1:2e095c3aef8490dac97f992fb73eff78cfaa9eec This is a direct commit to stable/11 since these files have already been removed in head. Reviewed by: sbruno, gjb Differential Revision: https://reviews.freebsd.org/D11542 2016-05-03T03:41:25Z Pedro F. Giffuni pfg@FreeBSD.org 2016-05-03T03:41:25Z urn:sha1:453130d9bfc1c6d68b366dfcb041689d69f81295 Most affect comments, very few have user-visible effects. 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-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-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 2014-11-20T20:09:18Z John Baldwin jhb@FreeBSD.org 2014-11-20T20:09:18Z urn:sha1:7e88c64c79a5c1fe6d8e0ececd0cb49555111861 - Don't recurse driver mutex. - Don't hold driver mutex across fubyte/subyte. - Replace fubyte/subyte loops with copyin/copyout calls. - Use relatively sane locking in wl_ioctl(). - Use bus space accessors instead of in*()/out*(). - Use callout(9) instead of timeout(9). - Stop watchdog timer in detach and don't hold mutex across bus_teardown_intr(). - Use device_printf() and if_printf(). - De-spl(). Tested by: no one 2014-09-19T03:51:26Z Gleb Smirnoff glebius@FreeBSD.org 2014-09-19T03:51:26Z urn:sha1:c8dfaf382fa6df9dc6fd1e1c3356e0c8bf607e6a