FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2016-08-19T22:27:14Z 2016-08-19T22:27:14Z John Baldwin jhb@FreeBSD.org 2016-08-19T22:27:14Z urn:sha1:09b9789b28dd8453a54cb424115f31a6d3672527 The wl(4) driver supports pre-802.11 PCCard wireless adapters that are slower than 802.11b. They do not work with any of the 802.11 framework and the driver hasn't been reported to actually work in a long time. Relnotes: yes 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 2013-10-26T17:58:36Z Gleb Smirnoff glebius@FreeBSD.org 2013-10-26T17:58:36Z urn:sha1:76039bc84fae9915788b54ff28fe0cc4876952d2 to this event, adding if_var.h to files that do need it. Also, include all includes that now are included due to implicit pollution via if_var.h Sponsored by: Netflix Sponsored by: Nginx, Inc. 2012-12-04T09:32:43Z Gleb Smirnoff glebius@FreeBSD.org 2012-12-04T09:32:43Z urn:sha1:c6499eccad497913a5025fbde8ae76da70e08043 malloc(9) flags in sys/dev. 2010-05-03T07:32:50Z Maxim Sobolev sobomax@FreeBSD.org 2010-05-03T07:32:50Z urn:sha1:e50d35e6c6c68e83fa329aff043d53ab84982fd3 queue length. The default value for this parameter is 50, which is quite low for many of today's uses and the only way to modify this parameter right now is to edit if_var.h file. Also add read-only sysctl with the same name, so that it's possible to retrieve the current value. MFC after: 1 month