linux-next.git/drivers/net, branch master

Merge branch 'headers' of git://git.infradead.org/users/willy/pagecache.git

2026-09-04T18:38:02+00:00

# Conflicts: # net/ceph/osd_client.c

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git

2026-09-04T17:21:58+00:00

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git

2026-09-04T17:21:57+00:00

Merge branch 'main' of https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git

2026-09-04T17:21:48+00:00

Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan.git

2026-09-04T16:46:19+00:00

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git

2026-09-04T16:46:18+00:00

wifi: libertas: validate firmware block extents

2026-09-04T10:14:44+00:00

check_fwfile_format() reads each block header and trusts its data length before proving that both fit in the firmware image. A truncated header or oversized block can therefore pass malformed extents to the download path. Require the remaining image to contain the complete header and payload before accepting each block. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260830140420.26399-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg

wifi: libertas_tf: validate firmware block extents

2026-09-04T10:14:26+00:00

check_fwfile_format() reads each block header and trusts its data length before proving that both fit in the firmware image. A truncated header or oversized block can therefore pass malformed extents to the download path. Require the remaining image to contain the complete header and payload before accepting each block. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260830124810.97223-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg

wifi: mwifiex: add dt flag to avoid conflict with platform reg domain

2026-09-04T10:11:36+00:00

WRT3200ACM and WRT32x routers always report a fixed US regulatory domain from the mwifiex ROM, which conflicts with the platform regulatory configuration on units sold outside the US market. For example: - phy0 mwlwifi 5 GHz, hard-coded region 98 EU mapped to FR - phy1 mwlwifi 2.4 GHz, hard-coded region 98 EU mapped to FR - phy2 mwifiex 2.4 and 5 GHz, hard-coded region US When the system boots, it detects a conflict between the user selected region and the radios, e.g. BG FR US, and applies extreme restrictions, preventing phy0 from starting on any DFS channel. phy2 works. Add a device-tree flag, which allows affected devices, where the radio conflicts with the platform to ignore the incorrect regulatory hint in the ROM of the radio, so the platform regulatory domain can be used. This does not allow the user to change the regulatory configuration of any radio. It only allows phy0 to start and operate according to its certified configuration. The change affects only platforms which explicitly define this flag, and helps overcome the incorrect behaviour of proprietary radio firmware. The change has been tested on OpenWrt and fixes the issue where phy0 does not start on WRT3200ACM-EU when a DFS channel is used [1] https://github.com/kaloz/mwlwifi/issues/173#issuecomment-307879699 [2] https://github.com/openwrt/openwrt/issues/9956 Signed-off-by: Georgi Valkov Link: https://patch.msgid.link/20260827175850.89395-2-gvalkov@gmail.com Signed-off-by: Johannes Berg

wifi: wfx: fix possible device hang during init

2026-09-04T08:48:49+00:00

The WFxxx device provides an SDIO interface. In addition to the usual in-band SDIO IRQ, the device also supports out-of-band IRQ line. OOB IRQ requires a specific initialization described in commit f00dc1d789e1c ("staging: wfx: poll IRQ during init"): When the chip starts in SDIO mode, the external IRQ (aka Out-Of-Band IRQ) cannot be used before to configure it. Therefore, the first exchanges with the chip have to be done without the OOB IRQ. This patch allow to poll the data until the OOB IRQ is correctly setup. In order to keep the code simpler, this patch also poll data even if OOB IRQ is not used. Commit 57aa557f110d9 ("staging: wfx: introduce a way to poll IRQ") announce some limitation about the data polling mechanism: This function [wfx_bh_poll_irq()] must used with care: if an IRQ fires while the host reads control register, the IRQ can be lost. However, with last analysis, it seems it does not only impact the IRQ. When this condition happen the hardware is lost and won't reply the next commands. The only way to recover the error is to pull the reset pin and bind the device again. Currently wfx_bh_poll_irq() is only used during the two first exchanges with the hardware. Therefore, it has been reported to only happen after a few hours of bind/rebind in a loop. This explain why it has not been reported before. Fortunately, wfx_bh_poll_irq() is only required for OOB IRQ, which is probably very marginal. The In-Band IRQ case also uses this function, but only to simplify the code. This patch limits the use of wfx_bh_poll_irq() to the OOB IRQ. The bus driver now tells wfx_probe() whether polling is necessary. When it is not (in-band SDIO IRQ and SPI), the IRQ is subscribed before the first exchange with the device and wfx_bh_poll_irq() is never called. When it is (SDIO with OOB IRQ), the behavior is unchanged: the control register is polled until the PDS file has configured the IRQ line. To conclude, In-Band users are now safe. Users of OOB IRQ will be still impacted by the bug, but there is nothing we can do (and nobody complained during the last 6 years). Fixes: f00dc1d789e1c ("staging: wfx: poll IRQ during init") Reported-by: Gerard Salvatella Reported-by: Lukas Stockmann Signed-off-by: Jérôme Pouiller Reviewed-by: Alexander Sverdlin Tested-by: Alexander Sverdlin Link: https://patch.msgid.link/20260901083548.113131-2-jerome.pouiller@silabs.com Signed-off-by: Johannes Berg