src/sys/dev/bwi, branch releng/12.4

bwi: Fix clang 14 warning about possible unaligned access

2022-02-16T20:25:26Z

On architectures with strict alignment requirements (e.g. arm), clang 14 warns about a packed struct which encloses a non-packed union: In file included from sys/dev/bwi/bwimac.c:79: sys/dev/bwi/if_bwivar.h:308:7: error: field iv_val within 'struct bwi_fw_iv' is less aligned than 'union (unnamed union at sys/dev/bwi/if_bwivar.h:305:2)' and is usually due to 'struct bwi_fw_iv' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] } iv_val; ^ It appears to help if you also add __packed to the inner union (i.e. iv_val). No change to the layout is intended. MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D34196 (cherry picked from commit 09d0a0fbe859e3fc7bbff0cf48c389b5e55b9e00)

MFC r344749-344750,344841-344843,345284,346405,346470,347140-347141,348331,

2020-09-10T19:00:17Z

349593,351868,353506-353507,353809,353853,353858,353860,356852,359063, 359158,360819,360888,360950-360951,360953-360954,360998,361009,361025, 361085,361087,361098,361106-361107,361115,361118,361319-361321,361486, 361560,361566,361626,361636-361637,361687,361726,361737-361738,361768, 361778,361811-361813,361819-361822,361825-361826,361834,361863-361864, 361878,361885-361886,362016,362084-362085,362156-362157,362161-362162, 362210-362213,362216,362256-362257,362671,362815-362816,363325, 363327-363328,364011-364012,364299,364301,364303,364312,364315, 364326-364327,364551,364553,364673,365097,365116,365125-365126, 365130-365131,365198,365419 by adrian(78), bcran(1), bz(13), cem(1), gavin(1), glebius(6), landonf(1), mjg(7) Merge WiFi net80211, drivers, and management in order to support better 11n and upcoming 11ac. This includes an ath(4) update, some run(4) 11n support, 11n for otus(4), A-MPDU, A-MSDU, A-MPDU+A-MSDU and Fast frames options, scanning fixes, enahnced PRIV checks for jails, restored parent device name printing, improvements for upcoming VHT support, lots of under-the-hood infrastructure improvements, new device ID, debug tools updates, some whistespace changes (to make future MFCs easier). This does not include (nost) epoch(9) related changes as too much other infrastructure was not merged for that. Bump __FreeBSD_veresion as this changes the priv(9) names (not know to be used externally), and net80211 structures. Tested on: some ath(4) AP, run(4) STA, and rtwn(4) STA Discussed with: adrian (extremly briefly) Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") [partially] Relnotes: yes

MFC r344990:

2019-03-28T09:16:00Z

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.

MFC r343474:

2019-02-10T20:59:35Z

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.

Reapply, with minor tweaks, r338025, from the original commit:

2018-09-26T17:12:14Z

Remove unused and easy to misuse PNP macro parameter Inspired by r338025, just remove the element size parameter to the MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to have correct pointer (or array) type. Since all invocations of the macro already had this property and the emitted PNP data continues to include the element size, there is no functional change. Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci (Note that coccinelle invokes diff(1) via a PATH search and expects diff to tolerate the -B flag, which BSD diff does not. So I had to link gdiff into PATH as diff to use spatch.) Tinderbox'd (-DMAKE_JUST_KERNELS). Approved by: re (glen)

Back out r338035 until Warner is finished churning GSoC PNP patches

2018-08-19T00:46:22Z

I was not aware Warner was making or planning to make forward progress in this area and have since been informed of that. It's easy to apply/reapply when churn dies down.

Remove unused and easy to misuse PNP macro parameter

2018-08-19T00:22:21Z

Inspired by r338025, just remove the element size parameter to the MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to have correct pointer (or array) type. Since all invocations of the macro already had this property and the emitted PNP data continues to include the element size, there is no functional change. Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci (Note that coccinelle invokes diff(1) via a PATH search and expects diff to tolerate the -B flag, which BSD diff does not. So I had to link gdiff into PATH as diff to use spatch.) Tinderbox'd (-DMAKE_JUST_KERNELS).

bwi(4): Set ic->ic_softc before bwi_getradiocaps to avoid bad deref

2018-08-10T13:06:14Z

Submitted by: François Revol Obtained from: Haiku (ba88131cfde64e21bedb4ebedd699cfa5e7fd314) MFC after: 1 week

Add PNP info to PCI attachment of bwi driver

2018-06-13T20:25:18Z

Reviewed by: imp, chuck Submitted by: Lakhan Shiva Kamireddy Sponsored by: Google, Inc. (GSoC 2018)

sys/dev: further adoption of SPDX licensing ID tags.

2017-11-27T14:52:40Z

Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.