FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F12.2 2019-05-12T12:30:45Z 2019-05-12T12:30:45Z Andriy Voskoboinyk avos@FreeBSD.org 2019-05-12T12:30:45Z urn:sha1:a3a0035ab4fe93445d286a9c565fe086e3341e3c urtw(4), otus(4), iwi(4): allow to set non-default MAC address via ifconfig(8) Was tested with Netgear WG111 v3 (RTL8187B, urtw(4)), STA mode. 2019-03-28T09:16:00Z Andriy Voskoboinyk avos@FreeBSD.org 2019-03-28T09:16:00Z urn:sha1:ed7073a725b8ac53dd8e87465c089aedd48fd948 Fix ieee80211_radiotap(9) usage in wireless drivers: - Alignment issues: * Add missing __packed attributes + padding across all drivers; in most places there was an assumption that padding will be always minimally suitable; in few places - e.g., in urtw(4) / rtwn(4) - padding was just missing. * Add __aligned(8) attribute for all Rx radiotap headers since they can contain 64-bit TSF timestamp; it cannot appear in Tx radiotap headers, so just drop the attribute here. Refresh ieee80211_radiotap(9) man page accordingly. - Since net80211 automatically updates channel frequency / flags in ieee80211_radiotap_chan_change() drop duplicate setup for these fields in drivers. 2019-02-10T20:59:35Z Andriy Voskoboinyk avos@FreeBSD.org 2019-02-10T20:59:35Z urn:sha1:37a5c307df28ce0e27ba41299fdb210d28f6ddbd Remove 2GHz channel list copies from wireless drivers. Wrap ieee80211_add_channel_list_2ghz into another function which supplies default (1-14) channel list to it and drop its copies from drivers. 2018-12-25T13:37:43Z Andriy Voskoboinyk avos@FreeBSD.org 2018-12-25T13:37:43Z urn:sha1:589d10b964c09cc6027801517de394842e1cf348 iwi(4): do not leak node reference when IWI_FLAG_ASSOCIATED flag is set. 2018-03-30T18:50:13Z Brooks Davis brooks@FreeBSD.org 2018-03-30T18:50:13Z urn:sha1:541d96aaaf46cde0f4247c226ed29d635b1915c4 This fixes 32-bit compat (no ioctl command defintions are required as struct ifreq is the same size). This is believed to be sufficent to fully support ifconfig on 32-bit systems. Reviewed by: kib Obtained from: CheriBSD MFC after: 1 week Relnotes: yes Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D14900 2018-03-08T22:04:54Z Konstantin Belousov kib@FreeBSD.org 2018-03-08T22:04:54Z urn:sha1:23fda0ad66861fd8cc95a98d7440cd41d3817e23 Sponsored by: The FreeBSD Foundation 2018-03-08T18:42:23Z Andriy Voskoboinyk avos@FreeBSD.org 2018-03-08T18:42:23Z urn:sha1:222a2f1de96f66236cd7b8df1ae14f237f5b7cf3 No functional change intended. 2018-01-21T15:42:36Z Pedro F. Giffuni pfg@FreeBSD.org 2018-01-21T15:42:36Z urn:sha1:ac2fffa4b74cd83963f0d462c379c7f50eeabf20 Uses of mallocarray(9). The use of mallocarray(9) has rocketed the required swap to build FreeBSD. This is likely caused by the allocation size attributes which put extra pressure on the compiler. Given that most of these checks are superfluous we have to choose better where to use mallocarray(9). We still have more uses of mallocarray(9) but hopefully this is enough to bring swap usage to a reasonable level. Reported by: wosch PR: 225197 2018-01-13T22:30:30Z Pedro F. Giffuni pfg@FreeBSD.org 2018-01-13T22:30:30Z urn:sha1:26c1d774b55c4db79bca772941883244986e6f44 Focus on code where we are doing multiplications within malloc(9). None of these is likely to overflow, however the change is still useful as some static checkers can benefit from the allocation attributes we use for mallocarray. This initial sweep only covers malloc(9) calls with M_NOWAIT. No good reason but I started doing the changes before r327796 and at that time it was convenient to make sure the sorrounding code could handle NULL values. 2018-01-02T00:07:28Z Adrian Chadd adrian@FreeBSD.org 2018-01-02T00:07:28Z urn:sha1:9fbe631a1ad7f8a1a2f45645d9c8dd50c2a8bb67 This removes the direct WME info access in the ieee80211com struct and instead provides a method of fetching the data. Right now it's a no-op but eventually it'll turn into a per-VAP method for drivers that support it (eg iwn, iwm, upcoming ath10k work) as things like p2p support require this kind of behaviour. Tested: * ath(4), STA and AP mode TODO: * yes, this is slightly stack size-y, but it is an important first step to get drivers migrated over to a sensible WME API. A lot of per-phy things need to be converted to per-VAP before P2P, 11ac firmware, etc stuff shows up.