src/sys/dev/bwi, branch release/13.1.0

bwi: Fix clang 14 warning about possible unaligned access

2022-02-16T20:24:53+00:00

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)

WiFi: fix ieee80211_media_change() callers

2020-09-07T15:35:40+00:00

In r178354 with the introduction of multi-bss ("vap") support factoring
out started and with r193340 ieee80211_media_change() no longer returned
ENETRESET but only 0 or error.
As ieee80211(9) tells the ieee80211_media_change() function should not
be called directly but is registered with ieee80211_vap_attach() instead.

Some drivers have not been fully converted.  After fixing the return
checking some of these functions were simply wrappers between
ieee80211_vap_attach() and ieee80211_media_change(), so remove the extra
function, where possible as well.

PR:		248955
Submitted by:	Tong Zhang (ztong0001 gmail.com) (original)
MFC after:	3 days
Sponsored by:	The FreeBSD Foundation

bwi: clean up empty lines in .c and .h files

2020-09-01T21:43:36+00:00

Widen EPOCH(9) usage in PCI WLAN drivers.

2020-01-30T10:28:01+00:00

Make sure all occurrences of ieee80211_input_xxx() in sys/dev are
covered by a network epoch section. Do not depend on the interrupt
handler nor any taskqueues being in a network epoch section.

This patch should unbreak the PCI WLAN drivers after r357004.

Pointy hat:	glebius@
Sponsored by:	Mellanox Technologies

Fix ieee80211_radiotap(9) usage in wireless drivers:

2019-03-11T01:27:01+00:00

- 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.

Tested with Netgear WG111 v3 (urtw(4)), STA mode.

MFC after:	2 weeks

Remove 2GHz channel list copies from wireless drivers.

2019-01-26T17:00:55+00:00

Wrap ieee80211_add_channel_list_2ghz into another function
which supplies default (1-14) channel list to it and drop
its copies from drivers.

Checked with RTL8188EE, country US / JP / KR / UA.

MFC after:	2 weeks

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

2018-09-26T17:12:14+00:00

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:22+00:00

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:21+00:00

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:14+00:00

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