[GIT PULL] wireless-next-2026-10-07

[GIT PULL] wireless-next-2026-10-07

[Johannes Berg]

Hi,

Nothing much going on in wireless-next. However, next time
I hope to land my RTNL-redux series which will (almost)
completely wean the wireless stack off the RTNL, except in
places where we need it for netdev register/unregister/etc.

I need to see what's going on with the per-netns mutex now,
can we already use that instead?

Please pull and let us know if there's any problem.

Thanks,
johannes



The following changes since commit f49defea7668d8c68ec19fa085ef3da6075561c7:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2026-10-01 11:02:44 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git tags/wireless-next-2026-10-07

for you to fetch changes up to b6f009284138884c4b07bbef7b07d780aa9b5daf:

  wifi: mac80211: use the AP address as RA for a 4-addr MLO station (2026-10-06 21:05:18 +0200)

----------------------------------------------------------------
Not too much going on:
 - brcmfmac: plenty of improvements
 - mac80211: NAN Instant Communications support
 - iwlegacy: remove sysfs
 - nxpwifi: IW610 support
 - couple of fixes for recent regressions

----------------------------------------------------------------
Aamir Ahmed (1):
      wifi: nxpwifi: validate variable IE lengths in beacon parser

Aaradhana Sahu (1):
      wifi: mac80211: Do not report BSS parameters in AP station info

Aloka Dixit (2):
      Revert "wifi: mac80211: do not use old MBSSID elements"
      wifi: mac80211: remove redundant null check in ieee80211_assign_beacon()

Andrei-Alexandru Bleortu (1):
      wifi: mac80211: keep the BSS color while a color change is pending

Benjamin Drung (2):
      wifi: brcmfmac: Add per-board clm_blob firmware binaries
      wifi: brcmfmac: Add clm_blob firmware for brcmfmac43456-sdio

Dan Carpenter (3):
      wifi: b43: don't pass unterminated string to sscanf()
      wifi: b43legacy: debugfs: NUL terminate string in debugfs
      wifi: carl9170: NUL terminate string in debugfs

Dominic White (1):
      wifi: cfg80211: allow zero HE OBSS PD offsets

Felix Fietkau (2):
      wifi: mac80211_hwsim: reserve headroom for software encryption
      wifi: mac80211: use the AP address as RA for a 4-addr MLO station

Girish Rudrappa (1):
      wifi: brcmfmac: Set extsae_pwe parameter to Infineon firmware in SAP mode

Heyang Tan (2):
      wifi: nxpwifi: bound histogram debugfs output
      wifi: nxpwifi: bound debug info output

Huang Xiangping (1):
      wifi: cfg80211: process pending events before connect/disconnect requests

Ilan Peer (11):
      wifi: cfg80211: nan: add Instant Communication support
      wifi: mac80211: nan: Update NAN configuration copy
      wifi: cfg80211: nan: check Rx registration for NAN beacons
      wifi: cfg80211: do not use NAN beacons to update the BSS table
      wifi: mac80211: nan: allow Rx registration for NAN beacons
      wifi: mac80211: accept NAN beacons only when IC is enabled
      wifi: ieee80211: add NAN service ID list attribute definitions
      wifi: mac80211_hwsim: nan: use ieee80211_is_nan_beacon() helper
      wifi: mac80211_hwsim: nan: prepare for more configurable NAN settings
      wifi: mac80211_hwsim: nan: Handle more of the NAN configuration
      wifi: mac80211_hwsim: add NAN Instant Communication support

Janne Grunau (1):
      wifi: brcmfmac: cfg80211: Report port_authorized for 4-way HS offload

Jeff Chen (6):
      mmc: sdio: add NXP IW610 device ID
      mmc: core: add NXP IW610 base ID and block size quirk
      wifi: nxpwifi: Add support for SDIO-based IW610
      wifi: nxpwifi: Limit channel width based on firmware capability
      wifi: nxpwifi: fix return value check in change_vif_to_sta/ap
      wifi: nxpwifi: fix missing error codes in _nxpwifi_fw_dpc()

Johannes Berg (7):
      wifi: mac80211: fix TPE in channel switch wrapper parsing
      wifi: ieee80211: type-check (extended) element functions
      wifi: cfg80211: add protected TWT assoc flag
      wifi: mac80211: fix and clean up protected TWT support
      wifi: mac80211: set SP in reg connectivity with any channel
      Merge tag 'nxpwifi-next-20260929-v3' of https://github.com/nxp-upstream/nxpwifi-next
      wifi: mac80211: fix non-MLD link ID handling

Manish Dharanenthiran (1):
      wifi: mac80211: Guard FILS discovery and unsolicited broadcast probe response

Nathan Chancellor (1):
      wifi: brcmsmac: Adjust txpwrindex value in nphy_ipa_rxcal_gaintbl_2GHz

Pengpeng Hou (1):
      wifi: brcmfmac: bound NVRAM comment parsing

Raj Ojha (1):
      wifi: mac80211: acquire wiphy lock for unlisted sdata teardown

Sebastian Reichel (1):
      wifi: brcmfmac: Improve D3 substate entering timeout handling

Stanislaw Gruszka (3):
      wifi: iwlegacy: set debug level using debugfs
      wifi: iwlegacy: 4965: remove custom sysfs files
      wifi: iwlegacy: 3945: remove custom sysfs files

Vinícius Ramon Fontanela (1):
      wifi: brcmfmac: allow ISO3166 fallback for BCM4350

 drivers/mmc/core/quirks.h                          |   3 +
 drivers/net/wireless/ath/carl9170/debug.c          |   5 +-
 drivers/net/wireless/broadcom/b43/debugfs.c        |   2 +-
 drivers/net/wireless/broadcom/b43legacy/debugfs.c  |   2 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c         |  98 ++++-
 .../broadcom/brcm80211/brcmfmac/cyw/core.c         |   6 +
 .../broadcom/brcm80211/brcmfmac/firmware.c         |  13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/fwvid.h   |  11 +
 .../wireless/broadcom/brcm80211/brcmfmac/pcie.c    |  10 +-
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c    |   3 +-
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c        |   2 +-
 drivers/net/wireless/intel/iwlegacy/3945-mac.c     | 441 +--------------------
 drivers/net/wireless/intel/iwlegacy/4965-mac.c     | 121 ------
 drivers/net/wireless/intel/iwlegacy/debug.c        |   3 +
 drivers/net/wireless/intel/iwlwifi/mld/iface.c     |   4 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c  |   3 +-
 drivers/net/wireless/nxp/nxpwifi/11ax.c            |   2 +
 drivers/net/wireless/nxp/nxpwifi/11n.c             |   4 +-
 drivers/net/wireless/nxp/nxpwifi/cfg80211.c        |   6 +-
 drivers/net/wireless/nxp/nxpwifi/debugfs.c         |  31 +-
 drivers/net/wireless/nxp/nxpwifi/fw.h              |   2 +
 drivers/net/wireless/nxp/nxpwifi/main.c            |  15 +-
 drivers/net/wireless/nxp/nxpwifi/scan.c            |  18 +
 drivers/net/wireless/nxp/nxpwifi/sdio.c            |  16 +
 drivers/net/wireless/nxp/nxpwifi/sdio.h            |   1 +
 drivers/net/wireless/nxp/nxpwifi/util.c            |  43 +-
 drivers/net/wireless/nxp/nxpwifi/util.h            |   1 +
 drivers/net/wireless/virtual/mac80211_hwsim_main.c |   8 +-
 drivers/net/wireless/virtual/mac80211_hwsim_nan.c  | 245 ++++++++++--
 drivers/net/wireless/virtual/mac80211_hwsim_nan.h  |   7 +
 include/linux/ieee80211-nan.h                      |  28 ++
 include/linux/ieee80211.h                          |  17 +-
 include/linux/mmc/sdio_ids.h                       |   2 +
 include/net/cfg80211.h                             |  28 +-
 include/net/mac80211.h                             |   4 +-
 include/uapi/linux/nl80211.h                       |  17 +
 net/mac80211/cfg.c                                 |  35 +-
 net/mac80211/ieee80211_i.h                         |   1 +
 net/mac80211/iface.c                               |  26 +-
 net/mac80211/main.c                                |   7 +-
 net/mac80211/mlme.c                                |  23 +-
 net/mac80211/parse.c                               |   5 +-
 net/mac80211/rx.c                                  |  20 +-
 net/mac80211/sta_info.c                            |  49 ++-
 net/mac80211/tx.c                                  |   4 +-
 net/mac80211/util.c                                |   4 +-
 net/wireless/core.c                                |  12 +
 net/wireless/nl80211.c                             |  36 +-
 net/wireless/scan.c                                |   9 +-
 net/wireless/sme.c                                 |  14 +
 50 files changed, 729 insertions(+), 738 deletions(-)

Re: [GIT PULL] wireless-next-2026-10-07

[Jakub Kicinski]

On Wed,  7 Oct 2026 22:57:00 +0200 Johannes Berg wrote:
> Nothing much going on in wireless-next. However, next time
> I hope to land my RTNL-redux series which will (almost)
> completely wean the wireless stack off the RTNL, except in
> places where we need it for netdev register/unregister/etc.
> 
> I need to see what's going on with the per-netns mutex now,
> can we already use that instead?

That's a Kuniyuki question (cced). I've been trying to move 
HW drivers out of rtnl_lock and under netdev->lock.
Most of the rtnl_lock contention I've seen in prod at Meta
is in init_net

Re: [GIT PULL] wireless-next-2026-10-07

[Kuniyuki Iwashima]

On Wed, Oct 7, 2026 at 4:36 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Wed,  7 Oct 2026 22:57:00 +0200 Johannes Berg wrote:
> > Nothing much going on in wireless-next. However, next time
> > I hope to land my RTNL-redux series which will (almost)
> > completely wean the wireless stack off the RTNL, except in
> > places where we need it for netdev register/unregister/etc.

That's great !

We saw a wifi driver holding RTNL long on Android.  Also,
I hope we could remove the long comment in __rtnl_unlock().

> >
> > I need to see what's going on with the per-netns mutex now,
> > can we already use that instead?

Do you mean moving net->rtnl_mutex out of Kconfig ?

Recently, I've been converting the first-class rtnetlink handlers
with dedicated locks, but others not worth the effort will simply
replace rtnl_lock() with rtnl_net_lock().

rtnl_net_lock() still acquires rtnl_lock(), but if we always compile
net->rtnl_mutex, using __rtnl_net_lock() for the latter should be
okay.


>
> That's a Kuniyuki question (cced). I've been trying to move
> HW drivers out of rtnl_lock and under netdev->lock.
> Most of the rtnl_lock contention I've seen in prod at Meta
> is in init_net

FWIW, I've still seen contention while creating/removing containers.

Re: [GIT PULL] wireless-next-2026-10-07

[Johannes Berg]

Hi Kuniyuki,

On Wed, 2026-10-07 at 19:05 -0700, Kuniyuki Iwashima wrote:
> On Wed, Oct 7, 2026 at 4:36 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > 
> > On Wed,  7 Oct 2026 22:57:00 +0200 Johannes Berg wrote:
> > > Nothing much going on in wireless-next. However, next time
> > > I hope to land my RTNL-redux series which will (almost)
> > > completely wean the wireless stack off the RTNL, except in
> > > places where we need it for netdev register/unregister/etc.
> 
> That's great !
> 
> We saw a wifi driver holding RTNL long on Android.

Well, _that_ mostly shouldn't have happened for a long time (since
5.12), though I actually learned yesterday that some android drivers
went to implement things with private ioctls because they (thought they)
needed the RTNL ... so, Android, take with a bag of salt.

> Also, I hope we could remove the long comment in __rtnl_unlock().

Couldn't we remove that today, by just __rtnl_unlock() in that place in
cfg80211? But it's not exported, for good reason, presumably.

But that's also irrelevant, because indeed after my patchset cfg80211
doesn't do that any more:
https://lore.kernel.org/linux-wireless/20261006100655.2687533-21-johannes@sipsolutions.net/

> > > I need to see what's going on with the per-netns mutex now,
> > > can we already use that instead?
> 
> Do you mean moving net->rtnl_mutex out of Kconfig ?

I have no idea what I'm talking about ;-)

> Recently, I've been converting the first-class rtnetlink handlers
> with dedicated locks, but others not worth the effort will simply
> replace rtnl_lock() with rtnl_net_lock().
> 
> rtnl_net_lock() still acquires rtnl_lock(), but if we always compile
> net->rtnl_mutex, using __rtnl_net_lock() for the latter should be
> okay.

OK so I (likely naively) thought the idea was that most things like
netdev registration/unregistration eventually move to rtnl_net_lock()?
Here are the places that still take RTNL in wifi after the patchset
above:

 - suspend/resume (not entirely sure - it goes to hw restart maybe)
 - hw restart (can unregister netdevs on failures)
 - rate control init in mac80211 (but that can be removed easily)
 - netdev registration
 - netdev unregistration
 - rfkill, to call dev_close()
 - wiphy registration/unregistration (might be possible to disentangle
   now)
 - network namespace destruction/exit
 - wiphy naming, but that can move to cfg80211_mtx now
 - some netlink dumps (related to the naming?)
 - testmode/vendor ... I guess we can't get rid of that,
   but no upstream drivers should have much here
 - interface/wdev start/stop
 - netns moves

(and a couple of places I should just fix).

So mostly that's relatively short-lived (like the wiphy naming stuff) or
related to network/netns maintenance where I'm not sure.

Thanks!

johannes

> 
> 
> > 
> > That's a Kuniyuki question (cced). I've been trying to move
> > HW drivers out of rtnl_lock and under netdev->lock.
> > Most of the rtnl_lock contention I've seen in prod at Meta
> > is in init_net
> 
> FWIW, I've still seen contention while creating/removing containers.

Re: [GIT PULL] wireless-next-2026-10-07

[Johannes Berg]

On Thu, 2026-10-08 at 09:44 +0200, Johannes Berg wrote:
> > Also, I hope we could remove the long comment in __rtnl_unlock().
> 
> Couldn't we remove that today, by just __rtnl_unlock() in that place in
> cfg80211? But it's not exported, for good reason, presumably.
> 
> But that's also irrelevant, because indeed after my patchset cfg80211
> doesn't do that any more:
> https://lore.kernel.org/linux-wireless/20261006100655.2687533-21-johannes@sipsolutions.net/
> 

FWIW, I double-checked and didn't find any other code in wifi that would
do the rtnl_lock(); lock(); rtnl_unlock() ... unlock(); thing, so that
really is gone once I merge that series (which I'm planning to do after
all the net-next pulls net etc. settling this week).

johannes

Re: [GIT PULL] wireless-next-2026-10-07

[Kuniyuki Iwashima]

On Thu, Oct 8, 2026 at 8:01 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Thu, 2026-10-08 at 09:44 +0200, Johannes Berg wrote:
> > > Also, I hope we could remove the long comment in __rtnl_unlock().
> >
> > Couldn't we remove that today, by just __rtnl_unlock() in that place in
> > cfg80211? But it's not exported, for good reason, presumably.
> >
> > But that's also irrelevant, because indeed after my patchset cfg80211
> > doesn't do that any more:
> > https://lore.kernel.org/linux-wireless/20261006100655.2687533-21-johannes@sipsolutions.net/
> >
>
> FWIW, I double-checked and didn't find any other code in wifi that would
> do the rtnl_lock(); lock(); rtnl_unlock() ... unlock(); thing, so that
> really is gone once I merge that series (which I'm planning to do after
> all the net-next pulls net etc. settling this week).

Thank you !  Great to hear that :)


> > OK so I (likely naively) thought the idea was that most things like
> > netdev registration/unregistration eventually move to rtnl_net_lock()?

Yes, and hopefully readers (lookup, etc.) will be converted to RCU.

Re: [GIT PULL] wireless-next-2026-10-07

[Johannes Berg]

On Wed, 2026-10-07 at 19:05 -0700, Kuniyuki Iwashima wrote:
> 
> Also,
> I hope we could remove the long comment in __rtnl_unlock().

So I sent my next PR, and we could therefore do that now. I also checked
across the other places in the tree, and isotp_release() was the only
one that seems to do something similar, keeping a socket pinned around
rtnl_unlock(), but I don't think that could cause a similar problem.

I was going to send a patch, but then I didn't (and am sending this mail
instead) because I'm not really sure what we should do with the WARN_ON.

On the one hand, it's no longer strictly _necessary_, code that queues a
work item (unregistered a netdev) and then calls __rtnl_unlock()
explicitly wouldn't have any expectation of completing that soon.

On the other hand, the next random code that acquired the rtnl and then
unlocked it would suddenly have to do the unregistration work for some
other code and it'd be accounted to that thread and cause latency there
(not that it can have much expectation on latency while using the rtnl
...), so in some way the WARN_ON() still seems justified?

Anyway, the cfg80211 bits are gone once the PR lands, so you can remove
the comment (and possibly WARN_ON) whichever way you prefer :)

johannes

Re: [GIT PULL] wireless-next-2026-10-07

[Oliver Hartkopp]

On 15.10.26 14:27, Johannes Berg wrote:
> On Wed, 2026-10-07 at 19:05 -0700, Kuniyuki Iwashima wrote:
>>
>> Also,
>> I hope we could remove the long comment in __rtnl_unlock().
> 
> So I sent my next PR, and we could therefore do that now. I also checked
> across the other places in the tree, and isotp_release() was the only
> one that seems to do something similar, keeping a socket pinned around
> rtnl_unlock(), but I don't think that could cause a similar problem.

If I got your claim correctly, I think we are solving this in this 
net-next PR too:

https://lore.kernel.org/linux-can/20261015015336.816543-8-mkl@pengutronix.de/

Best regards,
Oliver

> 
> I was going to send a patch, but then I didn't (and am sending this mail
> instead) because I'm not really sure what we should do with the WARN_ON.
> 
> On the one hand, it's no longer strictly _necessary_, code that queues a
> work item (unregistered a netdev) and then calls __rtnl_unlock()
> explicitly wouldn't have any expectation of completing that soon.
> 
> On the other hand, the next random code that acquired the rtnl and then
> unlocked it would suddenly have to do the unregistration work for some
> other code and it'd be accounted to that thread and cause latency there
> (not that it can have much expectation on latency while using the rtnl
> ...), so in some way the WARN_ON() still seems justified?
> 
> Anyway, the cfg80211 bits are gone once the PR lands, so you can remove
> the comment (and possibly WARN_ON) whichever way you prefer :)
> 
> johannes
> 

Re: [GIT PULL] wireless-next-2026-10-07

[Johannes Berg]

On Thu, 2026-10-15 at 14:43 +0200, Oliver Hartkopp wrote:
> 
> On 15.10.26 14:27, Johannes Berg wrote:
> > On Wed, 2026-10-07 at 19:05 -0700, Kuniyuki Iwashima wrote:
> > > 
> > > Also,
> > > I hope we could remove the long comment in __rtnl_unlock().
> > 
> > So I sent my next PR, and we could therefore do that now. I also checked
> > across the other places in the tree, and isotp_release() was the only
> > one that seems to do something similar, keeping a socket pinned around
> > rtnl_unlock(), but I don't think that could cause a similar problem.
> 
> If I got your claim correctly, I think we are solving this in this 
> net-next PR too:
> 
> https://lore.kernel.org/linux-can/20261015015336.816543-8-mkl@pengutronix.de/

I _think_ that's unrelated, but I might well not understand it
correctly. I was looking at the rtnl_unlock() portion, where that could
run a netdev todo item. Even with that change, you have

	rtnl_lock()
	lock_sock()
	...
	rtnl_unlock()
	...
	release_sock()

which looks sufficiently similar to

	rtnl_lock()
	wiphy_lock()
	rtnl_unlock()
	...
	wiphy_unlock()

that my search flagged it, but isn't really the same anyway. But I'm not
sure I understand the socket lock semantics and the socket notifier etc.
well enough that I should be commenting on this at all :)

johannes

Re: [GIT PULL] wireless-next-2026-10-07

[Oliver Hartkopp]

On 15.10.26 14:54, Johannes Berg wrote:
> On Thu, 2026-10-15 at 14:43 +0200, Oliver Hartkopp wrote:
>>
>> On 15.10.26 14:27, Johannes Berg wrote:
>>> On Wed, 2026-10-07 at 19:05 -0700, Kuniyuki Iwashima wrote:
>>>>
>>>> Also,
>>>> I hope we could remove the long comment in __rtnl_unlock().
>>>
>>> So I sent my next PR, and we could therefore do that now. I also checked
>>> across the other places in the tree, and isotp_release() was the only
>>> one that seems to do something similar, keeping a socket pinned around
>>> rtnl_unlock(), but I don't think that could cause a similar problem.
>>
>> If I got your claim correctly, I think we are solving this in this
>> net-next PR too:
>>
>> https://lore.kernel.org/linux-can/20261015015336.816543-8-mkl@pengutronix.de/
> 
> I _think_ that's unrelated, but I might well not understand it
> correctly. I was looking at the rtnl_unlock() portion, where that could
> run a netdev todo item. Even with that change, you have
> 
> 	rtnl_lock()
> 	lock_sock()
> 	...
> 	rtnl_unlock()
> 	...
> 	release_sock()
> 
> which looks sufficiently similar to
> 
> 	rtnl_lock()
> 	wiphy_lock()
> 	rtnl_unlock()
> 	...
> 	wiphy_unlock()
> 
> that my search flagged it, but isn't really the same anyway. But I'm not
> sure I understand the socket lock semantics and the socket notifier etc.
> well enough that I should be commenting on this at all :)

Right. It really seems to be unrelated. Sorry for the noise.

Btw. the locking scheme is ok for the isotp case because after 
rtnl_unlock(), the remaining operations only affect the socket itself 
and no longer interact with any netdevices.

Best regards,
Oliver

Re: [GIT PULL] wireless-next-2026-10-07

[patchwork-bot+netdevbpf]

Hello:

This pull request was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed,  7 Oct 2026 22:57:00 +0200 you wrote:
> Hi,
> 
> Nothing much going on in wireless-next. However, next time
> I hope to land my RTNL-redux series which will (almost)
> completely wean the wireless stack off the RTNL, except in
> places where we need it for netdev register/unregister/etc.
> 
> [...]

Here is the summary with links:
  - [GIT,PULL] wireless-next-2026-10-07
    https://git.kernel.org/netdev/net-next/c/991a02c88199

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html