Hi,
here's a pull request to net-next tree, more info below. Please let me know if
there are any problems.
Kalle
The following changes since commit 3fbf61207c66ff7ac9b60ab76d4bfd239f97e973:
Revert "mlx5 updates 2023-12-20" (2024-01-07 17:16:11 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git tags/wireless-next-2024-01-25
for you to fetch changes up to acf868ff60b1cd1f2e597f0b15aee2ff43f9fcd3:
wifi: iwlegacy: Use kcalloc() instead of kzalloc() (2024-01-23 13:51:24 +0200)
----------------------------------------------------------------
wireless-next patches for v6.9
The first "new features" pull request for v6.9. We have only driver
changes this time and most of them are for Realtek drivers. Really
nice to see activity in Broadcom drivers again.
Major changes:
rtwl8xxxu
* RTL8188F: concurrent interface support
* Channel Switch Announcement (CSA) support in AP mode
brcmfmac
* per-vendor feature support
* per-vendor SAE password setup
rtlwifi
* speed up USB firmware initialisation
----------------------------------------------------------------
Ajay Singh (4):
wifi: wilc1000: fix driver_handler when committing initial configuration
wifi: wilc1000: do not realloc workqueue everytime an interface is added
wifi: wilc1000: fix incorrect power down sequence
wifi: wilc1000: fix multi-vif management when deleting a vif
Alexis Lothoré (2):
wifi: wilc1000: fix declarations ordering
wifi: wilc1000: fix RCU usage in connect path
Arend van Spriel (5):
wifi: brcmfmac: export firmware interface functions
wifi: brcmfmac: add per-vendor feature detection callback
wifi: brcmfmac: move feature overrides before feature_disable
wifi: brcmfmac: avoid invalid list operation when vendor attach fails
wifi: brcmfmac: allow per-vendor event handling
Artem Chernyshev (1):
wifi: brcmsmac: phy: Remove unreachable code
Bitterblue Smith (5):
wifi: rtl8xxxu: Fix LED control code of RTL8192FU
wifi: rtl8xxxu: Fix off by one initial RTS rate
wifi: rtlwifi: rtl_usb: Use sync register writes
wifi: rtlwifi: rtl8192de: Don't read register in _rtl92de_query_rxphystatus
wifi: rtlwifi: Speed up firmware loading for USB
Cheng-Chieh Hsieh (1):
wifi: rtw89: 8922a: update the register used in DIG and the DIG flow
Chih-Kang Chang (2):
wifi: rtw89: fix HW scan timeout due to TSF sync issue
wifi: rtw89: fix disabling concurrent mode TX hang issue
Chin-Yen Lee (1):
wifi: rtw89: pci: use DBI function for 8852AE/8852BE/8851BE
Chung-Hsuan Hung (3):
wifi: rtw89: phy: add parser to support RX gain dynamic setting flow
wifi: rtw89: 8922a: set RX gain along with set_channel operation
wifi: rtw89: 8922a: add BTG functions to assist BT coexistence to control TX/RX
Colin Ian King (1):
wifi: rtw89: mac: Fix spelling mistakes "notfify" -> "notify"
Dmitry Antipov (3):
wifi: rtlwifi: cleanup few rtlxxx_tx_fill_desc() routines
wifi: rtw88: use kstrtoX_from_user() in debugfs handlers
wifi: rt2x00: simplify rt2x00crypto_rx_insert_iv()
Erick Archer (1):
wifi: iwlegacy: Use kcalloc() instead of kzalloc()
Hector Martin (2):
wifi: brcmfmac: cfg80211: Use WSEC to set SAE password
wifi: brcmfmac: Demote vendor-specific attach/detach messages to info
Jinjie Ruan (1):
wifi: mwifiex: debugfs: Drop unnecessary error check for debugfs_create_dir()
Martin Kaistra (24):
wifi: rtl8xxxu: remove assignment of priv->vif in rtl8xxxu_bss_info_changed()
wifi: rtl8xxxu: prepare supporting two virtual interfaces
wifi: rtl8xxxu: support setting linktype for both interfaces
wifi: rtl8xxxu: 8188e: convert usage of priv->vif to priv->vifs[0]
wifi: rtl8xxxu: support setting mac address register for both interfaces
wifi: rtl8xxxu: extend wifi connected check to both interfaces
wifi: rtl8xxxu: extend check for matching bssid to both interfaces
wifi: rtl8xxxu: don't parse CFO, if both interfaces are connected in STA mode
wifi: rtl8xxxu: support setting bssid register for multiple interfaces
wifi: rtl8xxxu: support multiple interfaces in set_aifs()
wifi: rtl8xxxu: support multiple interfaces in update_beacon_work_callback()
wifi: rtl8xxxu: support multiple interfaces in configure_filter()
wifi: rtl8xxxu: support multiple interfaces in watchdog_callback()
wifi: rtl8xxxu: support multiple interfaces in {add,remove}_interface()
wifi: rtl8xxxu: support multiple interfaces in bss_info_changed()
wifi: rtl8xxxu: support multiple interface in start_ap()
wifi: rtl8xxxu: add macids for STA mode
wifi: rtl8xxxu: remove obsolete priv->vif
wifi: rtl8xxxu: add hw crypto support for AP mode
wifi: rtl8xxxu: make supporting AP mode only on port 0 transparent
wifi: rtl8xxxu: declare concurrent mode support for 8188f
wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work
wifi: rtl8xxxu: enable channel switch support
wifi: rtl8xxxu: add missing number of sec cam entries for all variants
Ping-Ke Shih (35):
wifi: rtw89: phy: move bb_gain_info used by WiFi 6 chips to union
wifi: rtw89: phy: ignore special data from BB parameter file
wifi: rtw89: 8922a: add NCTL pre-settings for WiFi 7 chips
wifi: rtw89: phy: add BB wrapper of TX power for WiFi 7 chips
wifi: rtw89: phy: set channel_info for WiFi 7 chips
wifi: rtw88: 8822ce: refine power parameters for RFE type 5
wifi: rtw89: add firmware H2C command of BA CAM V1
wifi: rtw89: mac: add feature_init to initialize BA CAM V1
wifi: rtw89: add chip_ops::h2c_ba_cam() to configure BA CAM
wifi: rtw89: 8922a: update BA CAM number to 24
wifi: rtw89: fw: use struct to fill BA CAM H2C commands
wifi: rtw89: refine H2C command that pause transmitting by MAC ID
wifi: rtw89: add new H2C command to pause/sleep transmitting by MAC ID
wifi: rtw89: use struct to fill H2C command to download beacon frame
wifi: rtw89: add H2C command to download beacon frame for WiFi 7 chips
wifi: rtw89: add chip_ops::update_beacon to abstract update beacon operation
wifi: rtw89: adjust init_he_cap() to add EHT cap into iftype_data
wifi: rtw89: change supported bandwidths of chip_info to bit mask
wifi: rtw89: add EHT capabilities for WiFi 7 chips
wifi: rtw89: declare EXT NSS BW of VHT capability
wifi: rtw89: fw: add H2C command to update security CAM v2
wifi: rtw89: fw: fill CMAC table to associated station for WiFi 7 chips
wifi: rtw89: fw: add chip_ops to update CMAC table to associated station
wifi: rtw89: fw: update TX AMPDU parameter to CMAC table
wifi: rtw89: fw: add H2C command to reset CMAC table for WiFi 7
wifi: rtw89: fw: add H2C command to reset DMAC table for WiFi 7
wifi: rtw89: fw: use struct to fill JOIN H2C command
wifi: rtw89: fw: extend JOIN H2C command to support WiFi 7 chips
wifi: rtl8xxxu: convert EN_DESC_ID of TX descriptor to le32 type
wifi: rtl8xxxu: make instances of iface limit and combination to be static const
wifi: rtw89: add mlo_dbcc_mode for WiFi 7 chips
wifi: rtw89: 8922a: add chip_ops::{enable,disable}_bb_rf
wifi: rtw89: 8922a: add chip_ops related to BB init
wifi: rtw89: 8922a: add register definitions of H2C, C2H, page, RRSR and EDCCA
wifi: rtw89: 8922a: add TX power related ops
Po-Hao Huang (6):
wifi: rtw89: refine add_chan H2C command to encode_bits
wifi: rtw89: refine hardware scan C2H events
wifi: rtw89: Set default CQM config if not present
wifi: rtw89: disable RTS when broadcast/multicast
wifi: rtw89: fix null pointer access when abort scan
wifi: rtw89: add wait/completion for abort scan
Rahul Rameshbabu (4):
wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
wifi: b43: Stop/wake correct queue in PIO Tx path when QoS is disabled
wifi: b43: Stop correct queue in DMA worker when QoS is disabled
wifi: b43: Disable QoS for bcm4331
Ruan Jinjie (1):
wifi: mwifiex: Use helpers to check multicast addresses
Zheng Wang (1):
wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
Zong-Zhe Yang (2):
wifi: rtw89: 8852b: update TX power tables to R36
wifi: rtw89: 8851b: update TX power tables to R37
drivers/net/wireless/broadcom/b43/b43.h | 16 +
drivers/net/wireless/broadcom/b43/dma.c | 4 +-
drivers/net/wireless/broadcom/b43/main.c | 16 +-
drivers/net/wireless/broadcom/b43/pio.c | 6 +-
.../broadcom/brcm80211/brcmfmac/bca/core.c | 30 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 64 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.h | 2 +
.../wireless/broadcom/brcm80211/brcmfmac/common.c | 18 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 12 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 2 +-
.../broadcom/brcm80211/brcmfmac/cyw/core.c | 50 +-
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 11 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.c | 154 +++-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.h | 60 +-
.../wireless/broadcom/brcm80211/brcmfmac/fwil.c | 116 +--
.../wireless/broadcom/brcm80211/brcmfmac/fwil.h | 125 ++-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 2 +-
.../wireless/broadcom/brcm80211/brcmfmac/fwvid.c | 13 +-
.../wireless/broadcom/brcm80211/brcmfmac/fwvid.h | 48 +-
.../broadcom/brcm80211/brcmfmac/wcc/core.c | 31 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_cmn.c | 3 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_int.h | 2 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 11 +-
drivers/net/wireless/intel/iwlegacy/common.c | 4 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 +-
drivers/net/wireless/marvell/mwifiex/debugfs.c | 3 -
drivers/net/wireless/marvell/mwifiex/wmm.c | 2 +-
drivers/net/wireless/microchip/wilc1000/cfg80211.c | 12 +-
drivers/net/wireless/microchip/wilc1000/hif.c | 40 +-
drivers/net/wireless/microchip/wilc1000/netdev.c | 12 +-
drivers/net/wireless/microchip/wilc1000/wlan.c | 35 +-
drivers/net/wireless/microchip/wilc1000/wlan.h | 6 +
drivers/net/wireless/ralink/rt2x00/rt2x00crypto.c | 5 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 20 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c | 3 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188f.c | 2 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c | 1 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 1 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192f.c | 33 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8710b.c | 1 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c | 1 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 1 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 409 +++++++--
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 15 +
drivers/net/wireless/realtek/rtlwifi/efuse.c | 36 +-
drivers/net/wireless/realtek/rtlwifi/efuse.h | 4 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.c | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 3 -
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 6 +-
drivers/net/wireless/realtek/rtlwifi/usb.c | 164 ++--
drivers/net/wireless/realtek/rtlwifi/wifi.h | 38 +-
drivers/net/wireless/realtek/rtw88/debug.c | 44 +-
drivers/net/wireless/realtek/rtw88/pci.c | 4 +
drivers/net/wireless/realtek/rtw88/reg.h | 3 +
drivers/net/wireless/realtek/rtw89/cam.c | 61 ++
drivers/net/wireless/realtek/rtw89/cam.h | 109 +++
drivers/net/wireless/realtek/rtw89/chan.c | 2 +-
drivers/net/wireless/realtek/rtw89/core.c | 344 +++++---
drivers/net/wireless/realtek/rtw89/core.h | 136 ++-
drivers/net/wireless/realtek/rtw89/fw.c | 944 ++++++++++++++++++---
drivers/net/wireless/realtek/rtw89/fw.h | 810 ++++++++++--------
drivers/net/wireless/realtek/rtw89/mac.c | 96 ++-
drivers/net/wireless/realtek/rtw89/mac.h | 5 +-
drivers/net/wireless/realtek/rtw89/mac80211.c | 18 +-
drivers/net/wireless/realtek/rtw89/mac_be.c | 4 +-
drivers/net/wireless/realtek/rtw89/pci.c | 69 +-
drivers/net/wireless/realtek/rtw89/pci.h | 1 +
drivers/net/wireless/realtek/rtw89/phy.c | 46 +-
drivers/net/wireless/realtek/rtw89/phy.h | 72 ++
drivers/net/wireless/realtek/rtw89/phy_be.c | 312 +++++++
drivers/net/wireless/realtek/rtw89/reg.h | 278 +++++-
drivers/net/wireless/realtek/rtw89/rtw8851b.c | 15 +-
.../net/wireless/realtek/rtw89/rtw8851b_table.c | 72 +-
drivers/net/wireless/realtek/rtw89/rtw8852a.c | 11 +-
drivers/net/wireless/realtek/rtw89/rtw8852b.c | 15 +-
.../net/wireless/realtek/rtw89/rtw8852b_table.c | 142 ++--
drivers/net/wireless/realtek/rtw89/rtw8852c.c | 14 +-
drivers/net/wireless/realtek/rtw89/rtw8922a.c | 705 ++++++++++++++-
drivers/net/wireless/realtek/rtw89/wow.c | 2 +-
82 files changed, 4618 insertions(+), 1398 deletions(-)
On Thu, 25 Jan 2024 10:40:30 +0000 (UTC) Kalle Valo wrote:
> The first "new features" pull request for v6.9. We have only driver
> changes this time and most of them are for Realtek drivers. Really
> nice to see activity in Broadcom drivers again.
minor thing for a follow up:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49: warning: no newline at end of file
Hello:
This pull request was applied to netdev/net-next.git (main)
by Jakub Kicinski <[email protected]>:
On Thu, 25 Jan 2024 10:40:30 +0000 (UTC) you wrote:
> Hi,
>
> here's a pull request to net-next tree, more info below. Please let me know if
> there are any problems.
>
> Kalle
>
> [...]
Here is the summary with links:
- pull-request: wireless-next-2024-01-25
https://git.kernel.org/netdev/net-next/c/b54846da4594
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Jakub Kicinski <[email protected]> writes:
> On Thu, 25 Jan 2024 10:40:30 +0000 (UTC) Kalle Valo wrote:
>> The first "new features" pull request for v6.9. We have only driver
>> changes this time and most of them are for Realtek drivers. Really
>> nice to see activity in Broadcom drivers again.
>
> minor thing for a follow up:
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49:
> warning: no newline at end of file
Oh, sorry about that. Any tips how to detect this?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On January 26, 2024 7:01:18 AM Kalle Valo <[email protected]> wrote:
> Jakub Kicinski <[email protected]> writes:
>
>> On Thu, 25 Jan 2024 10:40:30 +0000 (UTC) Kalle Valo wrote:
>>> The first "new features" pull request for v6.9. We have only driver
>>> changes this time and most of them are for Realtek drivers. Really
>>> nice to see activity in Broadcom drivers again.
>>
>> minor thing for a follow up:
>>
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49:
>> warning: no newline at end of file
>
> Oh, sorry about that. Any tips how to detect this?
I thought checkpatch would signal that or is it a sparse warning. Anyway, I
can fix it.
Gr. AvS
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Arend Van Spriel <[email protected]> writes:
> On January 26, 2024 7:01:18 AM Kalle Valo <[email protected]> wrote:
>
>> Jakub Kicinski <[email protected]> writes:
>>
>>> On Thu, 25 Jan 2024 10:40:30 +0000 (UTC) Kalle Valo wrote:
>>>> The first "new features" pull request for v6.9. We have only driver
>>>> changes this time and most of them are for Realtek drivers. Really
>>>> nice to see activity in Broadcom drivers again.
>>>
>>> minor thing for a follow up:
>>>
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49:
>>> warning: no newline at end of file
>>
>> Oh, sorry about that. Any tips how to detect this?
>
> I thought checkpatch would signal that or is it a sparse warning.
I don't run checkpatch except for ath10k/ath11k/ath12k, too much noise.
I ended up adding this to my script:
for file in $(git ls-tree -r --name-only HEAD drivers/net/wireless/ net/wireless/ net/mac80211/); do if [ "$(tail -c 1 $file | cat -E)" != "$" ]; then echo $file: no newline at end of file; fi; done
> Anyway, I can fix it.
Thanks!
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On Fri, 26 Jan 2024 12:05:17 +0200 Kalle Valo wrote:
> > I thought checkpatch would signal that or is it a sparse warning.
>
> I don't run checkpatch except for ath10k/ath11k/ath12k, too much noise.
> I ended up adding this to my script:
We run build with sparse and W=1 and then diff the number of warnings
to weed out the pre-existing ones, FWIW.
Jakub Kicinski <[email protected]> writes:
> On Fri, 26 Jan 2024 12:05:17 +0200 Kalle Valo wrote:
>> > I thought checkpatch would signal that or is it a sparse warning.
>>
>> I don't run checkpatch except for ath10k/ath11k/ath12k, too much noise.
>> I ended up adding this to my script:
>
> We run build with sparse and W=1 and then diff the number of warnings
> to weed out the pre-existing ones, FWIW.
So for wireless and wireless-next I now check W=1 warnings every time I
push. We are mostly warning free now but I'm not checking the linker
warnings, for example the current MODULE_DESCRIPTION() warnings.
It's really annoying, and extra work, that people enable new W=1
warnings before fixing them. Could we somehow push back on those and
require that warnings are fixed before enabling with W=1 level?
In wireless there is a significant number of sparse warnings. I have
tried the cleanup people to fix them but it seems there's no interest,
instead we get to receive pointless cleanups wasting our time. <loud sigh>
BTW the 'no new line at end of file' warning is indeed from sparse, like
Arend suspected:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49: warning: no newline at end of file
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On Sat, 27 Jan 2024 12:08:59 +0200 Kalle Valo wrote:
> Jakub Kicinski <[email protected]> writes:
> >> I don't run checkpatch except for ath10k/ath11k/ath12k, too much noise.
> >> I ended up adding this to my script:
> >
> > We run build with sparse and W=1 and then diff the number of warnings
> > to weed out the pre-existing ones, FWIW.
>
> So for wireless and wireless-next I now check W=1 warnings every time I
> push. We are mostly warning free now but I'm not checking the linker
> warnings, for example the current MODULE_DESCRIPTION() warnings.
>
> It's really annoying, and extra work, that people enable new W=1
> warnings before fixing them. Could we somehow push back on those and
> require that warnings are fixed before enabling with W=1 level?
My quite possibly incorrect understanding is that "giving people time
to fix" is the main point of W=1 :( W=2 is for stuff which may false
positive, W=1 is for stuff which does not false positive but we can't
enable it in formal builds because the tree is full of it.
> In wireless there is a significant number of sparse warnings. I have
> tried the cleanup people to fix them but it seems there's no interest,
> instead we get to receive pointless cleanups wasting our time. <loud sigh>
Tell me about it.. :)
> BTW the 'no new line at end of file' warning is indeed from sparse, like
> Arend suspected:
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49: warning: no newline at end of file
BTW I'd happy to help you set up an instance of our build testing bot,
if you have a VM that can be used. It does take a bit of care and
feeding, but seeing the build failures in patchwork pays the time back.
Jakub Kicinski <[email protected]> writes:
> On Sat, 27 Jan 2024 12:08:59 +0200 Kalle Valo wrote:
>> Jakub Kicinski <[email protected]> writes:
>> >> I don't run checkpatch except for ath10k/ath11k/ath12k, too much noise.
>> >> I ended up adding this to my script:
>> >
>> > We run build with sparse and W=1 and then diff the number of warnings
>> > to weed out the pre-existing ones, FWIW.
>>
>> So for wireless and wireless-next I now check W=1 warnings every time I
>> push. We are mostly warning free now but I'm not checking the linker
>> warnings, for example the current MODULE_DESCRIPTION() warnings.
>>
>> It's really annoying, and extra work, that people enable new W=1
>> warnings before fixing them. Could we somehow push back on those and
>> require that warnings are fixed before enabling with W=1 level?
>
> My quite possibly incorrect understanding is that "giving people time
> to fix" is the main point of W=1 :( W=2 is for stuff which may false
> positive, W=1 is for stuff which does not false positive but we can't
> enable it in formal builds because the tree is full of it.
Ok, so keeping the code clean from W=1 warnings will be hard :/
>> In wireless there is a significant number of sparse warnings. I have
>> tried the cleanup people to fix them but it seems there's no interest,
>> instead we get to receive pointless cleanups wasting our time. <loud sigh>
>
> Tell me about it.. :)
>
>> BTW the 'no new line at end of file' warning is indeed from sparse, like
>> Arend suspected:
>>
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49:
>> warning: no newline at end of file
>
> BTW I'd happy to help you set up an instance of our build testing bot,
> if you have a VM that can be used. It does take a bit of care and
> feeding, but seeing the build failures in patchwork pays the time back.
We have talked about setting up your build bot for linux-wireless
patchwork project but never found the time to do anything. Also we don't
have a VM for it right now.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches