* Re: (subset) [PATCH v9 00/14] firmware: qcom: Add OP-TEE PAS service support
From: Bjorn Andersson @ 2026-07-13 15:06 UTC (permalink / raw)
To: konradybcio, Sumit Garg
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, robh, krzk+dt,
conor+dt, robin.clark, sean, akhilpo, lumag, abhinav.kumar,
jesszhan0024, marijn.suijten, airlied, simona, vikash.garodia,
bod, mchehab, elder, andrew+netdev, davem, edumazet, kuba, pabeni,
jjohnson, mathieu.poirier, trilokkumar.soni, mukesh.ojha,
pavan.kondeti, jorge.ramirez, tonyh, vignesh.viswanathan,
srinivas.kandagatla, amirreza.zarrabi, jenswi, op-tee, apurupa,
skare, linux-kernel, Sumit Garg
In-Reply-To: <20260702115835.167602-1-sumit.garg@kernel.org>
On Thu, 02 Jul 2026 17:28:16 +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Qcom platforms has the legacy of using non-standard SCM calls
> splintered over the various kernel drivers. These SCM calls aren't
> compliant with the standard SMC calling conventions which is a
> prerequisite to enable migration to the FF-A specifications from Arm.
>
> [...]
Applied, thanks!
[08/14] drm/msm: Switch to generic PAS TZ APIs
commit: 0be72be03ca7de55f22dd4c0622d81ac98aee38a
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] wifi: ath11k: implement custom wake_tx_queue with flow control
From: Jose Ignacio Tornos Martinez @ 2026-07-13 15:01 UTC (permalink / raw)
To: hujy652; +Cc: ath11k, ath12k, jjohnson, jtornosm, linux-kernel, linux-wireless
In-Reply-To: <20260711153336.542-1-hujy652@gmail.com>
Hi Zhi-Jun,
Thank you for the review.
> In wake_tx_queue:
> ring_id = txq->ac % ar->ab->hw_params.hal_params->num_tx_rings;
>
>In ath11k_dp_tx which is called by ath11k_mac_op_tx:
>ring_selector = ab->hw_params.hw_ops->get_ring_selector(skb);
> ti.ring_id = ring_selector % num_tx_rings;
>
> Are you sure ring_id will be the same?
You're right — txq->ac % num_tx_rings doesn't match
get_ring_selector(skb) % num_tx_rings on all platforms.
In v1 the ring identification was only correct for platforms where the ring
selector happens to coincide with the AC, but not for platforms.
I will send a v2 trying to solve this globally for all the platforms.
> Also mgmt frames use a different path.
Correct — management frames go through WMI, not the TCL data rings, so they
are not affected. The flow control applies to data frames, which are the
ones causing the problem since they use different TCL rings depending on the
platform's ring selector.
Best regards,
Jose Ignacio
^ permalink raw reply
* Re: [PATCH 01/13 RFC net-next] net: ipv4: introduce CONFIG_IPV4 to decouple the IPv4 stack
From: Fernando Fernandez Mancera @ 2026-07-13 14:57 UTC (permalink / raw)
To: Arnd Bergmann, Netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Ahern, Simon Horman, Ido Schimmel, Jason Gunthorpe,
Leon Romanovsky, Andrew Lunn, Anthony L Nguyen, Przemek Kitszel,
Elad Nachman, Saeed Mahameed, Tariq Toukan, Mark Bloch,
Petr Machata, Edward Cree, Maxime Coquelin, Alexandre Torgue,
Arend van Spriel, Miri Korenblit, Keith Busch, Jens Axboe,
Christoph Hellwig, Sagi Grimberg, Chaitanya Kulkarni,
Saurav Kashyap, Javed Hasan, GR-QLogic-Storage-Upstream,
James E . J . Bottomley, Martin K. Petersen, Nilesh Javali,
Manish Rangankar, Varun Prakash, Alexander Viro,
Christian Brauner, Jan Kara, David Howells, Marc Dionne,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Marek Lindner,
Simon Wunderlich, Antonio Quartulli, Sven Eckelmann,
Nikolay Aleksandrov, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, Johannes Berg, Matthieu Baerts, Mat Martineau,
Geliang Tang, Julian Anastasov, Aaron Conole, Eelco Chaudron,
Ilya Maximets, Allison Henderson, Jamal Hadi Salim, Jiri Pirko,
Marcelo Ricardo Leitner, Xin Long, D. Wythe, Dust Li,
Sidraya Jayagond, Wenjia Zhang, Mahanta Jambigi, Tony Lu, Wen Gu,
Jon Maloy, Steffen Klassert, Herbert Xu, Vikas Gupta,
Rajashekar Hudumula, Justin Chen, Bhargava Marreddy,
Nicolai Buchwitz, Florian Fainelli, Heiner Kallweit,
Krzysztof Kozlowski, Russell King, Yao Zi, Yanteng Si,
Maxime Chevallier, Julian Braha, Joey Lu, Shangjuan Wei,
Chen-Yu Tsai, Inochi Amaoto, Lad, Prabhakar, Qingfang Deng,
Greg Kroah-Hartman, Eric Biggers, Ethan Nelson-Moore,
Ard Biesheuvel, Dmitry Safonov, Kuniyuki Iwashima, Alyssa Ross,
linux-rdma, linux-kernel, intel-wired-lan@lists.osuosl.org,
open list:NETRONOME ETHERNET DRIVERS, linux-net-drivers,
linux-stm32, linux-arm-kernel, linux-wireless, brcm80211,
brcm80211-dev-list.pdl, linux-nvme, linux-scsi, target-devel,
linux-fsdevel, linux-afs, linux-nfs, b.a.t.m.a.n,
open list:ETHERNET BRIDGE, netfilter-devel, coreteam, mptcp,
lvs-devel, dev, rds-devel, linux-sctp, linux-s390,
open list:TIPC NETWORK LAYER
In-Reply-To: <713178ff-0fb2-4f1b-90bc-9841cd42c20e@app.fastmail.com>
On 7/13/26 4:22 PM, Arnd Bergmann wrote:
> On Mon, Jul 13, 2026, at 16:00, Fernando Fernandez Mancera wrote:
>> On 7/12/26 1:01 PM, Arnd Bergmann wrote:
>>> On Sun, Jul 12, 2026, at 03:38, Fernando Fernandez Mancera wrote:
>>>> Historically, the IPv4 protocol has been linked to the core INET
>>>> subsystem. Because shared infrastructure like the TCP/UDP engine,
>>>> routing or INET hashtables live inside net/ipv4/, it has been impossible
>>>> to compile a kernel with only IPv6 support.
>>>>
>>>> This patch introduces the CONFIG_IPV4 Kconfig symbol, which is set to
>>>> 'def_bool y' for now. This does not allow to completely disable the
>>>> IPv4 stack yet but it lays the necessary build-system work for that
>>>> goal.
>>>
>>> I expect this will cause additional (trivial) build regression in the
>>> next step when randconfig builds run into obscure corner cases, either
>>> with INET=y IPV4=n IPV6=y or with INET=y IPV4=n IPV6=n.
>>>
>>> I can probably give your patch (with IPV4 visible or disabled) an
>>> early go on the randconfig tree to find these more quickly.
>>> If I run into regressions, should I just add more 'depends on IPV4',
>>> or do you have other plans?
>>>
>>
>> Yes, I have a job running randconfig and verifying nothing breaks. If
>> something breaks and it isn't core networking stack I would just make
>> the Kconfig symbol depend on IPv4.
>>
>> Then later we will have more time to write a dedicate patch so it does
>> not depend on IPv4.
>
> Ok
>
>>> Should we have some logic to ensure that at least one of IPV4 or
>>> IPV6 is enabled? I think this would work
>>>
>>> config IPV4
>>> bool "The IPv4 protocol" if IPV6
>>> default INET
>>>
>>> which only allows turning IPV4 off if IPV6 has enabled.
>>>
>>
>> I do wonder, should we? I mean, I didn't try it off but I don't see why
>> we should not allow a pure L2 system..
>
> I expected a pure L2 system to be CONFIG_ETHERNET=y CONFIG_INET=n.
>
> Which user-visible parts of CONFIG_INET would you want keep working
> when both v4 and v6 are disabled?
>
Yes, you are right. So I think introducing something as you proposed
makes sense. Right now I cannot think about something needed from INET
for pure L2.
Thank you!
Fernando.
^ permalink raw reply
* Re: [PATCH 01/13 RFC net-next] net: ipv4: introduce CONFIG_IPV4 to decouple the IPv4 stack
From: Arnd Bergmann @ 2026-07-13 14:22 UTC (permalink / raw)
To: Fernando Fernandez Mancera, Netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Ahern, Simon Horman, Ido Schimmel, Jason Gunthorpe,
Leon Romanovsky, Andrew Lunn, Anthony L Nguyen, Przemek Kitszel,
Elad Nachman, Saeed Mahameed, Tariq Toukan, Mark Bloch,
Petr Machata, Edward Cree, Maxime Coquelin, Alexandre Torgue,
Arend van Spriel, Miri Korenblit, Keith Busch, Jens Axboe,
Christoph Hellwig, Sagi Grimberg, Chaitanya Kulkarni,
Saurav Kashyap, Javed Hasan, GR-QLogic-Storage-Upstream,
James E . J . Bottomley, Martin K. Petersen, Nilesh Javali,
Manish Rangankar, Varun Prakash, Alexander Viro,
Christian Brauner, Jan Kara, David Howells, Marc Dionne,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Marek Lindner,
Simon Wunderlich, Antonio Quartulli, Sven Eckelmann,
Nikolay Aleksandrov, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, Johannes Berg, Matthieu Baerts, Mat Martineau,
Geliang Tang, Julian Anastasov, Aaron Conole, Eelco Chaudron,
Ilya Maximets, Allison Henderson, Jamal Hadi Salim, Jiri Pirko,
Marcelo Ricardo Leitner, Xin Long, D. Wythe, Dust Li,
Sidraya Jayagond, Wenjia Zhang, Mahanta Jambigi, Tony Lu, Wen Gu,
Jon Maloy, Steffen Klassert, Herbert Xu, Vikas Gupta,
Rajashekar Hudumula, Justin Chen, Bhargava Marreddy,
Nicolai Buchwitz, Florian Fainelli, Heiner Kallweit,
Krzysztof Kozlowski, Russell King, Yao Zi, Yanteng Si,
Maxime Chevallier, Julian Braha, Joey Lu, Shangjuan Wei,
Chen-Yu Tsai, Inochi Amaoto, Lad, Prabhakar, Qingfang Deng,
Greg Kroah-Hartman, Eric Biggers, Ethan Nelson-Moore,
Ard Biesheuvel, Dmitry Safonov, Kuniyuki Iwashima, Alyssa Ross,
linux-rdma, linux-kernel, intel-wired-lan@lists.osuosl.org,
open list:NETRONOME ETHERNET DRIVERS, linux-net-drivers,
linux-stm32, linux-arm-kernel, linux-wireless, brcm80211,
brcm80211-dev-list.pdl, linux-nvme, linux-scsi, target-devel,
linux-fsdevel, linux-afs, linux-nfs, b.a.t.m.a.n,
open list:ETHERNET BRIDGE, netfilter-devel, coreteam, mptcp,
lvs-devel, dev, rds-devel, linux-sctp, linux-s390,
open list:TIPC NETWORK LAYER
In-Reply-To: <2256daf4-d03c-4a57-9d72-7a388d823f18@suse.de>
On Mon, Jul 13, 2026, at 16:00, Fernando Fernandez Mancera wrote:
> On 7/12/26 1:01 PM, Arnd Bergmann wrote:
>> On Sun, Jul 12, 2026, at 03:38, Fernando Fernandez Mancera wrote:
>>> Historically, the IPv4 protocol has been linked to the core INET
>>> subsystem. Because shared infrastructure like the TCP/UDP engine,
>>> routing or INET hashtables live inside net/ipv4/, it has been impossible
>>> to compile a kernel with only IPv6 support.
>>>
>>> This patch introduces the CONFIG_IPV4 Kconfig symbol, which is set to
>>> 'def_bool y' for now. This does not allow to completely disable the
>>> IPv4 stack yet but it lays the necessary build-system work for that
>>> goal.
>>
>> I expect this will cause additional (trivial) build regression in the
>> next step when randconfig builds run into obscure corner cases, either
>> with INET=y IPV4=n IPV6=y or with INET=y IPV4=n IPV6=n.
>>
>> I can probably give your patch (with IPV4 visible or disabled) an
>> early go on the randconfig tree to find these more quickly.
>> If I run into regressions, should I just add more 'depends on IPV4',
>> or do you have other plans?
>>
>
> Yes, I have a job running randconfig and verifying nothing breaks. If
> something breaks and it isn't core networking stack I would just make
> the Kconfig symbol depend on IPv4.
>
> Then later we will have more time to write a dedicate patch so it does
> not depend on IPv4.
Ok
>> Should we have some logic to ensure that at least one of IPV4 or
>> IPV6 is enabled? I think this would work
>>
>> config IPV4
>> bool "The IPv4 protocol" if IPV6
>> default INET
>>
>> which only allows turning IPV4 off if IPV6 has enabled.
>>
>
> I do wonder, should we? I mean, I didn't try it off but I don't see why
> we should not allow a pure L2 system..
I expected a pure L2 system to be CONFIG_ETHERNET=y CONFIG_INET=n.
Which user-visible parts of CONFIG_INET would you want keep working
when both v4 and v6 are disabled?
Arnd
^ permalink raw reply
* Re: [PATCH v3 0/3] wifi: carl9170: firmware trust boundary hardening
From: Jeff Johnson @ 2026-07-13 14:05 UTC (permalink / raw)
To: Christian Lamparter, Tristan Madani
Cc: Johannes Berg, linux-wireless, linux-kernel, Tristan Madani
In-Reply-To: <20260421134929.325662-1-tristmd@gmail.com>
On Tue, 21 Apr 2026 13:49:25 +0000, Tristan Madani wrote:
> From: Tristan Madani <tristan@talencesecurity.com>
>
> This series adds missing bounds checks for firmware-controlled fields
> in the carl9170 USB driver.
>
> Patch 1 bounds the cmd callback memcpy to prevent heap overflow from
> an oversized firmware response. Patch 2 fixes an off-by-two in the TX
> status handler. Patch 3 caps the failover copy to rx_failover_missing
> bytes, using min_t per Christian Lamparter.
>
> [...]
Applied, thanks!
[1/3] wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read
commit: 4cde55b2feff9504d1f993ab80e84e7ccb62791c
[2/3] wifi: carl9170: fix OOB read from off-by-two in TX status handler
commit: a3f42f1049ad80c65560d2b078ad426c3134f78d
[3/3] wifi: carl9170: fix buffer overflow in rx_stream failover path
commit: a1a21995c2e1cc2ca6b2226cfe4f5f018370182a
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] wifi: ath6kl: firmware trust boundary hardening
From: Jeff Johnson @ 2026-07-13 14:05 UTC (permalink / raw)
To: Johannes Berg, Tristan Madani
Cc: linux-wireless, linux-kernel, Tristan Madani
In-Reply-To: <20260421135009.348084-1-tristmd@gmail.com>
On Tue, 21 Apr 2026 13:50:06 +0000, Tristan Madani wrote:
> From: Tristan Madani <tristan@talencesecurity.com>
>
> This series adds missing bounds checks for firmware-controlled fields
> in the Qualcomm ath6kl driver.
>
> Patch 1 returns early on invalid ADDBA window size. Patch 2 validates
> connect event IE lengths. Patch 3 checks TX complete handler num_msg.
>
> [...]
Applied, thanks!
[2/3] wifi: ath6kl: fix OOB read from firmware IE lengths in connect event
commit: 6b47b29730de3232b919d8362749f6814c5f2a33
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH wireless v4 3/3] wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler
From: Jeff Johnson @ 2026-07-13 14:05 UTC (permalink / raw)
To: Kalle Valo, Tristan Madani
Cc: Johannes Berg, linux-wireless, linux-kernel, tristan
In-Reply-To: <20260625232907.3620746-1-tristmd@gmail.com>
On Thu, 25 Jun 2026 23:29:07 +0000, Tristan Madani wrote:
> The firmware-controlled num_msg field (u8, 0-255) drives the loop in
> ath6kl_wmi_tx_complete_event_rx() without validation against the buffer
> length. This allows out-of-bounds reads of up to 1020 bytes past the
> WMI event buffer when the firmware sends an inflated num_msg.
>
> Add a check that the buffer is large enough to hold the fixed struct
> and the num_msg variable-length entries.
>
> [...]
Applied, thanks!
[3/3] wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler
commit: 3a21c89215cc18f1a97c5e5bfd1da6d4f3d44495
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5] wifi: ath6kl: fix OOB access from firmware ADDBA window size
From: Jeff Johnson @ 2026-07-13 14:05 UTC (permalink / raw)
To: linux-wireless, linux-kernel, Tristan Madani
Cc: vasanthakumar.thiagarajan, johannes, tristan, stable
In-Reply-To: <20260702005020.708717-1-tristmd@gmail.com>
On Thu, 02 Jul 2026 00:50:20 +0000, Tristan Madani wrote:
> aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied
> win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not
> return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to
> compute a kzalloc size and stored in rxtid->hold_q_sz, leading to
> zero-size or overflowed allocations and subsequent out-of-bounds access.
>
> Clean up any previously active aggregation session for the TID first,
> then return early when win_sz is out of the valid range, instead of
> proceeding with a broken allocation size.
>
> [...]
Applied, thanks!
[1/1] wifi: ath6kl: fix OOB access from firmware ADDBA window size
commit: 44126b6994eeb28f2103b638e698f40a1244f327
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2] ath12k: fix NULL pointer dereference in rhash table destroy
From: Jeff Johnson @ 2026-07-13 14:05 UTC (permalink / raw)
To: jjohnson, Jose Ignacio Tornos Martinez
Cc: linux-wireless, ath12k, linux-kernel, stable
In-Reply-To: <20260615112103.601982-1-jtornosm@redhat.com>
On Mon, 15 Jun 2026 13:21:03 +0200, Jose Ignacio Tornos Martinez wrote:
> When unbinding the ath12k driver, kernel NULL pointer dereferences
> occur in irq_work_sync() called from rhashtable_destroy().
>
> Two hash tables are affected:
> 1. ath12k_link_sta hash table in ath12k_base
> 2. ath12k_dp_link_peer hash table in ath12k_dp
>
> [...]
Applied, thanks!
[1/1] ath12k: fix NULL pointer dereference in rhash table destroy
commit: 70231dcd782201579990ded73e0435d18bb524ca
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-current] wifi: ath12k: Fix low MLO RX throughput on WCN7850
From: Jeff Johnson @ 2026-07-13 14:05 UTC (permalink / raw)
To: ath12k, Yingying Tang; +Cc: linux-wireless, yintang
In-Reply-To: <20260610053315.2249912-1-yingying.tang@oss.qualcomm.com>
On Tue, 09 Jun 2026 22:33:15 -0700, Yingying Tang wrote:
> Commit [1] introduced a regression causing severely degraded MLO RX
> throughput on WCN7850.
>
> On WCN7850, there is only a single ar instance, but MLO uses two
> link IDs. ath12k_dp_peer->hw_links[] is indexed using ar->hw_link_id,
> which causes both MLO link IDs to be stored at the same index.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: Fix low MLO RX throughput on WCN7850
commit: a2fe9dc70f3b8d5716fbcfed5fbfb9cf3948d402
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 01/13 RFC net-next] net: ipv4: introduce CONFIG_IPV4 to decouple the IPv4 stack
From: Fernando Fernandez Mancera @ 2026-07-13 14:00 UTC (permalink / raw)
To: Arnd Bergmann, Netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Ahern, Simon Horman, Ido Schimmel, Jason Gunthorpe,
Leon Romanovsky, Andrew Lunn, Anthony L Nguyen, Przemek Kitszel,
Elad Nachman, Saeed Mahameed, Tariq Toukan, Mark Bloch,
Petr Machata, Edward Cree, Maxime Coquelin, Alexandre Torgue,
Arend van Spriel, Miri Korenblit, Keith Busch, Jens Axboe,
Christoph Hellwig, Sagi Grimberg, Chaitanya Kulkarni,
Saurav Kashyap, Javed Hasan, GR-QLogic-Storage-Upstream,
James E . J . Bottomley, Martin K. Petersen, Nilesh Javali,
Manish Rangankar, Varun Prakash, Alexander Viro,
Christian Brauner, Jan Kara, David Howells, Marc Dionne,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Marek Lindner,
Simon Wunderlich, Antonio Quartulli, Sven Eckelmann,
Nikolay Aleksandrov, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, Johannes Berg, Matthieu Baerts, Mat Martineau,
Geliang Tang, Julian Anastasov, Aaron Conole, Eelco Chaudron,
Ilya Maximets, Allison Henderson, Jamal Hadi Salim, Jiri Pirko,
Marcelo Ricardo Leitner, Xin Long, D. Wythe, Dust Li,
Sidraya Jayagond, Wenjia Zhang, Mahanta Jambigi, Tony Lu, Wen Gu,
Jon Maloy, Steffen Klassert, Herbert Xu, Vikas Gupta,
Rajashekar Hudumula, Justin Chen, Bhargava Marreddy,
Nicolai Buchwitz, Florian Fainelli, Heiner Kallweit,
Krzysztof Kozlowski, Russell King, Yao Zi, Yanteng Si,
Maxime Chevallier, Julian Braha, Joey Lu, Shangjuan Wei,
Chen-Yu Tsai, Inochi Amaoto, Lad, Prabhakar, Qingfang Deng,
Greg Kroah-Hartman, Eric Biggers, Ethan Nelson-Moore,
Ard Biesheuvel, Dmitry Safonov, Kuniyuki Iwashima, Alyssa Ross,
linux-rdma, linux-kernel, intel-wired-lan@lists.osuosl.org,
open list:NETRONOME ETHERNET DRIVERS, linux-net-drivers,
linux-stm32, linux-arm-kernel, linux-wireless, brcm80211,
brcm80211-dev-list.pdl, linux-nvme, linux-scsi, target-devel,
linux-fsdevel, linux-afs, linux-nfs, b.a.t.m.a.n,
open list:ETHERNET BRIDGE, netfilter-devel, coreteam, mptcp,
lvs-devel, dev, rds-devel, linux-sctp, linux-s390,
open list:TIPC NETWORK LAYER
In-Reply-To: <12ffac6a-649a-4e4a-8d12-0b48171e1d95@app.fastmail.com>
On 7/12/26 1:01 PM, Arnd Bergmann wrote:
> On Sun, Jul 12, 2026, at 03:38, Fernando Fernandez Mancera wrote:
>> Historically, the IPv4 protocol has been linked to the core INET
>> subsystem. Because shared infrastructure like the TCP/UDP engine,
>> routing or INET hashtables live inside net/ipv4/, it has been impossible
>> to compile a kernel with only IPv6 support.
>>
>> This patch introduces the CONFIG_IPV4 Kconfig symbol, which is set to
>> 'def_bool y' for now. This does not allow to completely disable the
>> IPv4 stack yet but it lays the necessary build-system work for that
>> goal.
>
> I expect this will cause additional (trivial) build regression in the
> next step when randconfig builds run into obscure corner cases, either
> with INET=y IPV4=n IPV6=y or with INET=y IPV4=n IPV6=n.
>
> I can probably give your patch (with IPV4 visible or disabled) an
> early go on the randconfig tree to find these more quickly.
> If I run into regressions, should I just add more 'depends on IPV4',
> or do you have other plans?
>
Yes, I have a job running randconfig and verifying nothing breaks. If
something breaks and it isn't core networking stack I would just make
the Kconfig symbol depend on IPv4.
Then later we will have more time to write a dedicate patch so it does
not depend on IPv4.
> Should we have some logic to ensure that at least one of IPV4 or
> IPV6 is enabled? I think this would work
>
> config IPV4
> bool "The IPv4 protocol" if IPV6
> default INET
>
> which only allows turning IPV4 off if IPV6 has enabled.
>
I do wonder, should we? I mean, I didn't try it off but I don't see why
we should not allow a pure L2 system..
Thanks,
Fernando.
^ permalink raw reply
* [PATCH] wifi: mt76: mt7996: validate default EEPROM firmware size
From: Laxman Acharya Padhya @ 2026-07-13 11:54 UTC (permalink / raw)
To: nbd, lorenzo, ryder.lee, shayne.chen, sean.wang
Cc: linux-wireless, stable, Laxman Acharya Padhya
The default EEPROM firmware is parsed and copied as a full EEPROM
without checking its length. A truncated file can make the driver
read beyond the firmware buffer during variant validation or the
fallback copy.
Reject files shorter than MT7996_EEPROM_SIZE before parsing or
copying the firmware.
Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
Cc: stable@vger.kernel.org
Signed-off-by: Laxman Acharya Padhya <acharyalaxman8848@gmail.com>
---
drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c
index ac05f7d75d63..ec33521db564 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7996/eeprom.c
@@ -150,6 +150,12 @@ mt7996_eeprom_check_or_use_default(struct mt7996_dev *dev, bool use_default)
goto out;
}
+ if (fw->size < MT7996_EEPROM_SIZE) {
+ dev_err(dev->mt76.dev, "Invalid default bin size\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
if (!use_default && mt7996_eeprom_variant_valid(dev, fw->data))
goto out;
--
2.51.2
^ permalink raw reply related
* Re: [PATCH] wifi: brcmfmac: set F2 blocksize to 256 for BCM43752
From: Gokul Sivakumar @ 2026-07-13 11:51 UTC (permalink / raw)
To: Arend van Spriel
Cc: LiangCheng Wang, Kalle Valo, Angus Ainslie, Wig Cheng,
linux-wireless, brcm80211, brcm80211-dev-list.pdl, linux-kernel,
stable, wlan-kernel-dev-list
In-Reply-To: <36f4388a-b856-438c-8ef4-795a7b1eda3e@broadcom.com>
On 07/13, Arend van Spriel wrote:
> On 13/07/2026 10:50, LiangCheng Wang wrote:
> > The BCM43752 is not reliable with the default 512-byte SDIO function 2
> > block size: on an i.MX8MP board with an AMPAK AP6275S module at
> > SDR104 / 200 MHz, an iperf TX stress test kills WLAN within seconds:
> >
> > mmc_submit_one: CMD53 sg block write failed -84
> > brcmf_sdio_dpc: failed backplane access over SDIO, halting operation
> >
> > Commit d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
> > set up the 43752 like the 4373 for the F2 watermark but missed the F2
> > block size, which the 4373 limits to 256 bytes. The vendor driver
> > (bcmdhd) also programs a 256-byte F2 block size for this chip and runs
> > the same hardware without errors.
> >
> > Group the 43752 with the 4373, matching the F2 watermark handling.
> > With this change a 10-minute bidirectional iperf3 soak completes with
> > zero SDIO errors at ~270 Mbit/s in each direction.
> >
> > Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
> > Cc: stable@vger.kernel.org # <= 6.16 needs the CYPRESS_43752 id name
>
> Looks good to me but the stable instruction looks confusion. What do you
> mean. If there is no 43752 support there is no need for this patch, right?
Arend, one year back, from Infineon we had submitted a patch [1] to correct
the vendor ownership of 43752. i.e, SDIO_DEVICE_ID_BROADCOM_CYPRESS_4373 got
replaced with SDIO_DEVICE_ID_BROADCOM_43752.
So in the older kernel versions like v6.16.x which does not have patch [1],
the 43752 support exists, but with SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752.
So his instruction is to, again replace SDIO_DEVICE_ID_BROADCOM_4373 with
SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752 in his patch [2] while cherry-picking
to the older stable trees.
Rather than that, I would suggest to cherry-pick both the patches [1] & [2]
to stable trees, since the new patch [2] is dependent on existing patch [1].
[1] https://lore.kernel.org/linux-wireless/20250724101136.6691-1-gokulkumar.sivakumar@infineon.com/
[2] https://lore.kernel.org/linux-wireless/20260713-b43752-f2-blksz-v1-1-8697fcfeaef4@gmail.com/
Gokul
> > Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
> > ---
>
^ permalink raw reply
* [PATCH v2] wifi: ath11k: fix resource leak on error in ext IRQ setup
From: ZhaoJinming @ 2026-07-13 10:59 UTC (permalink / raw)
To: Baochen Qiang, Jeff Johnson
Cc: linux-wireless, ath11k, linux-kernel, ZhaoJinming
In-Reply-To: <e94de910-0a15-4b82-b006-03da98305e9b@oss.qualcomm.com>
In ath11k_ahb_config_irq(), when a CE request_irq() fails, the function
returns the error immediately without freeing the CE IRQs that were
successfully registered in previous loop iterations. The probe error
path does not call ath11k_ahb_free_irq() either, so the previously
registered CE IRQ handlers remain attached to the interrupt lines and
are never released.
In ath11k_ahb_config_ext_irq(), when an external request_irq() fails,
the error is only logged and the loop continues. The function then
returns 0 indicating success, leaving the device in a partially
configured state where some external IRQs are not registered. This
causes enable_irq()/disable_irq()/free_irq() to be called on
unregistered IRQs during runtime and remove/shutdown, triggering
WARN_ON(!desc->action), and missing interrupt handlers lead to data
loss.
Additionally, if alloc_netdev_dummy() fails for a later IRQ group, the
function returns -ENOMEM without freeing the ext IRQs and napi_ndev
that were successfully set up for earlier groups.
Fix all three issues: propagate the error up to the caller and unwind
all successfully registered IRQs and allocated resources on failure.
Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
---
Changes in v2:
- Move `irq_grp` declaration from for-loop body to function scope to fix
compile error in err_request_irq error path.
- Set ret = -ENOMEM before goto err_request_irq on alloc_netdev_dummy()
failure to avoid returning uninitialized value.
- When ath11k_ahb_config_ext_irq() fails, unwind the already-registered
CE IRQs via a shared err_ce_irq cleanup path to avoid leaking them.
drivers/net/wireless/ath/ath11k/ahb.c | 48 ++++++++++++++++++++++++++--
1 file changed, 44 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/ahb.c b/drivers/net/wireless/ath/ath11k/ahb.c
index f566d699d074..11bafbd94aff 100644
--- a/drivers/net/wireless/ath/ath11k/ahb.c
+++ b/drivers/net/wireless/ath/ath11k/ahb.c
@@ -524,20 +524,24 @@ static irqreturn_t ath11k_ahb_ext_interrupt_handler(int irq, void *arg)
static int ath11k_ahb_config_ext_irq(struct ath11k_base *ab)
{
struct ath11k_hw_params *hw = &ab->hw_params;
+ struct ath11k_ext_irq_grp *irq_grp;
int i, j;
int irq;
int ret;
for (i = 0; i < ATH11K_EXT_IRQ_GRP_NUM_MAX; i++) {
- struct ath11k_ext_irq_grp *irq_grp = &ab->ext_irq_grp[i];
+ irq_grp = &ab->ext_irq_grp[i];
u32 num_irq = 0;
irq_grp->ab = ab;
irq_grp->grp_id = i;
irq_grp->napi_ndev = alloc_netdev_dummy(0);
- if (!irq_grp->napi_ndev)
- return -ENOMEM;
+ if (!irq_grp->napi_ndev) {
+ ret = -ENOMEM;
+ irq_grp->num_irq = 0;
+ goto err_request_irq;
+ }
netif_napi_add(irq_grp->napi_ndev, &irq_grp->napi,
ath11k_ahb_ext_grp_napi_poll);
@@ -600,11 +604,25 @@ static int ath11k_ahb_config_ext_irq(struct ath11k_base *ab)
if (ret) {
ath11k_err(ab, "failed request_irq for %d\n",
irq);
+ irq_grp->num_irq = j;
+ goto err_request_irq;
}
}
}
return 0;
+
+err_request_irq:
+ for ( ; i >= 0; i--) {
+ irq_grp = &ab->ext_irq_grp[i];
+ for (j = irq_grp->num_irq - 1; j >= 0; j--)
+ free_irq(ab->irq_num[irq_grp->irqs[j]], irq_grp);
+ if (irq_grp->napi_ndev) {
+ netif_napi_del(&irq_grp->napi);
+ free_netdev(irq_grp->napi_ndev);
+ }
+ }
+ return ret;
}
static int ath11k_ahb_config_irq(struct ath11k_base *ab)
@@ -629,15 +647,30 @@ static int ath11k_ahb_config_irq(struct ath11k_base *ab)
ret = request_irq(irq, ath11k_ahb_ce_interrupt_handler,
IRQF_TRIGGER_RISING, irq_name[irq_idx],
ce_pipe);
- if (ret)
- return ret;
+ if (ret) {
+ ath11k_err(ab, "failed request_irq for %d\n", irq);
+ goto err_ce_irq;
+ }
ab->irq_num[irq_idx] = irq;
}
/* Configure external interrupts */
ret = ath11k_ahb_config_ext_irq(ab);
+ if (ret) {
+ ath11k_err(ab, "failed to configure ext irq: %d\n", ret);
+ goto err_ce_irq;
+ }
+
+ return 0;
+err_ce_irq:
+ for (i--; i >= 0; i--) {
+ if (ath11k_ce_get_attr_flags(ab, i) & CE_ATTR_DIS_INTR)
+ continue;
+ free_irq(ab->irq_num[ATH11K_IRQ_CE0_OFFSET + i],
+ &ab->ce.ce_pipe[i]);
+ }
return ret;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] wifi: brcmfmac: set F2 blocksize to 256 for BCM43752
From: Arend van Spriel @ 2026-07-13 10:51 UTC (permalink / raw)
To: LiangCheng Wang, Kalle Valo, Angus Ainslie
Cc: Wig Cheng, linux-wireless, brcm80211, brcm80211-dev-list.pdl,
linux-kernel, stable
In-Reply-To: <20260713-b43752-f2-blksz-v1-1-8697fcfeaef4@gmail.com>
On 13/07/2026 10:50, LiangCheng Wang wrote:
> The BCM43752 is not reliable with the default 512-byte SDIO function 2
> block size: on an i.MX8MP board with an AMPAK AP6275S module at
> SDR104 / 200 MHz, an iperf TX stress test kills WLAN within seconds:
>
> mmc_submit_one: CMD53 sg block write failed -84
> brcmf_sdio_dpc: failed backplane access over SDIO, halting operation
>
> Commit d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
> set up the 43752 like the 4373 for the F2 watermark but missed the F2
> block size, which the 4373 limits to 256 bytes. The vendor driver
> (bcmdhd) also programs a 256-byte F2 block size for this chip and runs
> the same hardware without errors.
>
> Group the 43752 with the 4373, matching the F2 watermark handling.
> With this change a 10-minute bidirectional iperf3 soak completes with
> zero SDIO errors at ~270 Mbit/s in each direction.
>
> Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
> Cc: stable@vger.kernel.org # <= 6.16 needs the CYPRESS_43752 id name
Looks good to me but the stable instruction looks confusion. What do you
mean. If there is no 43752 support there is no need for this patch, right?
Regards,
Arend
> Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
> ---
^ permalink raw reply
* Re: [PATCH v3] wifi: mt76: mt792x: fix use-after-free in mt76_rx_poll_complete
From: Eason Lai (賴易聖) @ 2026-07-13 9:34 UTC (permalink / raw)
To: JB Tsai (蔡志彬), nbd@nbd.name,
lorenzo@kernel.org
Cc: Deren Wu (武德仁), Ryder Lee,
Quan Zhou (周全),
Litien Chang (張立典),
linux-wireless@vger.kernel.org, Sean Wang,
Leon Yen (顏良儒),
linux-mediatek@lists.infradead.org
In-Reply-To: <KL1PR03MB7079CDD6006DA83B2E0DD32D97E62@KL1PR03MB7079.apcprd03.prod.outlook.com>
On Mon, 2026-06-15 at 02:17 +0000, Eason Lai (賴易聖) wrote:
> After looking into the mac80211 STA removal flow, I didn't notice
> that synchronize_net() is invoked after mt76_sta_pre_rcu_remove().
> You are right. I will check mt7925_change_vif_links(). Thanks for the
> suggestion.
>
> Best regards,
> Eason
>
> -----Original Message-----
> From: Felix Fietkau <nbd@nbd.name>
> Sent: Monday, June 1, 2026 7:13 PM
> To: JB Tsai (蔡志彬) <Jb.Tsai@mediatek.com>; lorenzo@kernel.org
> Cc: linux-wireless@vger.kernel.org;
> linux-mediatek@lists.infradead.org; Deren Wu (武德仁)
> <Deren.Wu@mediatek.com>; Sean Wang <Sean.Wang@mediatek.com>; Quan
> Zhou (周全) <Quan.Zhou@mediatek.com>; Ryder Lee
> <Ryder.Lee@mediatek.com>; Leon Yen (顏良儒) <Leon.Yen@mediatek.com>;
> Litien Chang (張立典) <Litien.Chang@mediatek.com>; Eason Lai (賴易聖)
> <Eason.Lai@mediatek.com>
> Subject: Re: [PATCH v3] wifi: mt76: mt792x: fix use-after-free in
> mt76_rx_poll_complete
>
> On 06.05.26 10:43, JB Tsai wrote:
> > From: Eason Lai <Eason.Lai@mediatek.com>
> >
> > A use-after-free issue occurs in mt76_rx_poll_complete due to a
> > race
> > condition. The STA has already been removed, but the rx_status
> > still
> > had a pointer to the wcid in the STA.
> >
> > Use wcid_idx instead of storing the wcid pointer, and look up the
> > wcid
> > via rcu_dereference() by wcid_idx.
> Unless I'm misreading something, it seems to me that this patch
> papers over a different bug instead of fixing the root cause.
> Right now the rx processing code relies on RCU to protect the wcid
> and sta data structures.
> The rcu lock/unlock around polling also seems correct to me.
>
> Are the freed wcid pointers maybe related to a vif sta instead of an
> actual station? The use of devm_kfree in mt7925_change_vif_links
> looks suspicious to me.
>
> Please let me know if I'm missing something here.
>
> - Felix
The new patch is posted here:
https://lore.kernel.org/all/20260701010654.956863-1-eason.lai@mediatek.com/
Best regards,
Eason
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: validate regulatory capability phy_id
From: Rameshkumar Sundaram @ 2026-07-13 9:29 UTC (permalink / raw)
To: Pengpeng Hou, Jeff Johnson; +Cc: linux-wireless, ath11k, linux-kernel
In-Reply-To: <20260704011040.26233-1-pengpeng@iscas.ac.cn>
On 7/4/2026 6:40 AM, Pengpeng Hou wrote:
> ath11k_wmi_tlv_ext_hal_reg_caps() copies firmware regulatory
> capability records into soc->hal_reg_cap[] using reg_cap.phy_id as
> the destination index. The loop count is bounded by num_phy, but the
> phy_id embedded in each record is not checked against the fixed
> MAX_RADIOS-sized destination array.
>
> Reject firmware records whose phy_id does not fit soc->hal_reg_cap[]
> before copying the parsed capability.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [ath-next] wifi: ath10k: trigger hardware recovery upon rx failures
From: Rameshkumar Sundaram @ 2026-07-13 9:26 UTC (permalink / raw)
To: Manikanta Pubbisetty, ath10k; +Cc: linux-wireless
In-Reply-To: <20260710060406.3323260-1-manikanta.pubbisetty@oss.qualcomm.com>
On 7/10/2026 11:34 AM, Manikanta Pubbisetty wrote:
[PATCH ath-next] Prefix missing in subject
> When an error occurs during RX packet processing (e.g., MSDU done
> failure), the driver sets rx_confused and drops all subsequent RX
> packets until a Wi-Fi ON/OFF cycle clears the flag. This can leave
> the device in a bad state where it cannot process RX data traffic.
>
> Instead of leaving the device in such a state, trigger hardware
> recovery so that such an error state can be reset and the device
> can function again normally.
>
> Tested-on: WCN3990 hw1.0 WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
> Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
> Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
>
> Signed-off-by: Manikanta Pubbisetty <manikanta.pubbisetty@oss.qualcomm.com>
Actual change looks fine,
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v2] wifi: ath12k: Set IEEE80211_OFFLOAD_ENCAP_4ADDR after tx_encap_type vdev param
From: Rameshkumar Sundaram @ 2026-07-13 9:12 UTC (permalink / raw)
To: Tamizh Chelvam Raja, ath12k; +Cc: linux-wireless
In-Reply-To: <20260701182428.906441-1-tamizh.raja@oss.qualcomm.com>
On 7/1/2026 11:54 PM, Tamizh Chelvam Raja wrote:
> Currently, IEEE80211_OFFLOAD_ENCAP_4ADDR is set when
> IEEE80211_OFFLOAD_ENCAP_ENABLED is present in vif->offload_flags
> at the beginning of ath12k_mac_update_vif_offload().
>
> However, if the WMI vdev set_param for tx_encap_type fails,
> IEEE80211_OFFLOAD_ENCAP_ENABLED is cleared but
> IEEE80211_OFFLOAD_ENCAP_4ADDR remains set, leaving the flags in
> an inconsistent state.
>
> Fix this by setting IEEE80211_OFFLOAD_ENCAP_4ADDR only after the
> tx_encap_type has been configured via the WMI vdev set parameter.
>
> Compile tested only.
>
> Fixes: 729cad3c3c9e ("wifi: ath12k: Add 4-address mode support for eth offload")
>
> Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: Fix ath12k_wifi7_mac_op_tx() style issues
From: Rameshkumar Sundaram @ 2026-07-13 9:09 UTC (permalink / raw)
To: Jeff Johnson, Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260711-ath12k_wifi7_mac_op_tx-line-length-v1-1-10e4899b98ef@oss.qualcomm.com>
On 7/11/2026 9:01 PM, Jeff Johnson wrote:
> Commit e47d6c9bb416 ("wifi: ath12k: Advertise multicast Ethernet
> encapsulation offload support") introduced a few style issues.
>
> ath12k-check reports:
> drivers/net/wireless/ath/ath12k/wifi7/hw.c:1042: line length of 92 exceeds 90 columns
>
> And automated review did not like one if/else that did not use braces
> for a single statement that also included a block comment.
>
> Fix these issues.
>
> Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* [PATCH] wifi: brcmfmac: set F2 blocksize to 256 for BCM43752
From: LiangCheng Wang @ 2026-07-13 8:50 UTC (permalink / raw)
To: Arend van Spriel, Kalle Valo, Angus Ainslie
Cc: Wig Cheng, linux-wireless, brcm80211, brcm80211-dev-list.pdl,
linux-kernel, stable, LiangCheng Wang
The BCM43752 is not reliable with the default 512-byte SDIO function 2
block size: on an i.MX8MP board with an AMPAK AP6275S module at
SDR104 / 200 MHz, an iperf TX stress test kills WLAN within seconds:
mmc_submit_one: CMD53 sg block write failed -84
brcmf_sdio_dpc: failed backplane access over SDIO, halting operation
Commit d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
set up the 43752 like the 4373 for the F2 watermark but missed the F2
block size, which the 4373 limits to 256 bytes. The vendor driver
(bcmdhd) also programs a 256-byte F2 block size for this chip and runs
the same hardware without errors.
Group the 43752 with the 4373, matching the F2 watermark handling.
With this change a 10-minute bidirectional iperf3 soak completes with
zero SDIO errors at ~270 Mbit/s in each direction.
Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization")
Cc: stable@vger.kernel.org # <= 6.16 needs the CYPRESS_43752 id name
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com>
---
The failure was isolated by testing combinations of scatter-gather
support and F2 block size, all at SDR104 / 200 MHz, with an iperf
multi-stream stress test plus a 5-10 minute bidirectional iperf3 soak:
sg/glom F2 blksz result
on 512 fatal halt within seconds (CMD53 write -84,
"failed backplane access", wlan dead)
txglom off, 512 survives, but ~14 recoverable CMD53 errors/min
rx glom on
off 512 firmware PSM watchdog reset after ~3 minutes
off 256 0 errors, but TX limited to ~142 Mbit/s
on 256 0 errors, RX 265 / TX 273 Mbit/s (this patch)
So the corruption tracks the 512-byte block size, not scatter-gather;
glomming only amplifies it. The vendor bcmdhd driver logging "set
sd_f2_blocksize 256" at probe is what pointed at the missing override.
The BCM43751 shares the 43752 firmware handling and F2 watermark case
and may need the same fix, but I have no 43751 hardware to verify.
Tested on:
- i.MX8MP (usdhc SDIO host, AMPAK AP6275S module) with Linux kernel
6.12.34 plus this patch
The touched code is unchanged between 6.12 and the current tree apart
from the 74e2ef72bd4b ("wifi: brcmfmac: fix 43752 SDIO FWVID
incorrectly labelled as Cypress (CYW)") rename; stable trees before it
need the old SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752 name to build.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index d24b80e492e084160e1d085b8c20242de3e07c28..3f7a05c4d27ad4c284a6ecc7f0b014a1e985526d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -911,6 +911,7 @@ int brcmf_sdiod_probe(struct brcmf_sdio_dev *sdiodev)
return ret;
}
switch (sdiodev->func2->device) {
+ case SDIO_DEVICE_ID_BROADCOM_43752:
case SDIO_DEVICE_ID_BROADCOM_CYPRESS_4373:
f2_blksz = SDIO_4373_FUNC2_BLOCKSIZE;
break;
---
base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
change-id: 20260713-b43752-f2-blksz-efda1de3ede9
Best regards,
--
LiangCheng Wang <zaq14760@gmail.com>
^ permalink raw reply related
* [PATCH ath-current 8/8] wifi: ath12k: resolve PENDING ML peer ID from MLO_PEER_MAP HTT event
From: Baochen Qiang @ 2026-07-13 7:33 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, ath12k, Baochen Qiang
In-Reply-To: <20260713-ath12k-fw-allocated-ml-peer-id-v1-0-d0a2a1a519eb@oss.qualcomm.com>
Add ath12k_dp_peer_fixup_peer_id() and call it from the
HTT_T2H_MSG_TYPE_MLO_RX_PEER_MAP handler. For devices where the
firmware allocates the MLD peer ID, this is the point at which
all data structures that were left with ATH12K_MLO_PEER_ID_PENDING
or ATH12K_MLO_PEER_ID_INVALID get their real ID:
- dp_peer->peer_id is updated and the dp_peer is published into
dp_hw->dp_peers[];
- every existing dp_link_peer in dp_peer->link_peers[] gets its
ml_id set to the same value;
- ahsta->ml_peer_id is updated to the same value so peer_assoc,
sta_state and cleanup paths see a consistent ID.
Devices with host_alloc_ml_id == true also receive the same HTT
event, but the firmware-reported ID always matches the
host-allocated one and everything has already been populated by
ath12k_dp_peer_create(); Skips the helper entirely on those devices.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221039
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/core.c | 2 ++
drivers/net/wireless/ath/ath12k/core.h | 1 +
drivers/net/wireless/ath/ath12k/dp_htt.c | 19 +++++++++++
drivers/net/wireless/ath/ath12k/dp_peer.c | 52 +++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath12k/dp_peer.h | 2 ++
drivers/net/wireless/ath/ath12k/mac.c | 24 ++++++++++++++
6 files changed, 100 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
index 0e7c732f8222..cf9c5b068fa6 100644
--- a/drivers/net/wireless/ath/ath12k/core.c
+++ b/drivers/net/wireless/ath/ath12k/core.c
@@ -1547,6 +1547,8 @@ static void ath12k_core_pre_reconfigure_recovery(struct ath12k_base *ab)
}
wiphy_unlock(ah->hw->wiphy);
+
+ complete(&ah->peer_ml_id_done);
}
wake_up(&ab->wmi_ab.tx_credits_wq);
diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
index 8769b41f5db5..30726e580833 100644
--- a/drivers/net/wireless/ath/ath12k/core.h
+++ b/drivers/net/wireless/ath/ath12k/core.h
@@ -795,6 +795,7 @@ struct ath12k_hw {
bool regd_updated;
bool use_6ghz_regd;
bool host_alloc_ml_id;
+ struct completion peer_ml_id_done;
u8 num_radio;
diff --git a/drivers/net/wireless/ath/ath12k/dp_htt.c b/drivers/net/wireless/ath/ath12k/dp_htt.c
index 150b190f9c7f..68968f96b4f1 100644
--- a/drivers/net/wireless/ath/ath12k/dp_htt.c
+++ b/drivers/net/wireless/ath/ath12k/dp_htt.c
@@ -6,6 +6,7 @@
#include "core.h"
#include "peer.h"
+#include "dp_peer.h"
#include "htc.h"
#include "dp_htt.h"
#include "debugfs_htt_stats.h"
@@ -582,6 +583,7 @@ static void ath12k_dp_htt_mlo_peer_map_handler(struct ath12k_base *ab,
struct htt_t2h_mlo_peer_map_event *ev = &resp->mlo_peer_map_ev;
u16 raw_peer_id, peer_id, addr_h16;
u8 peer_addr[ETH_ALEN];
+ int ret;
if (skb->len < sizeof(*ev)) {
ath12k_warn(ab, "unexpected htt mlo peer map event len %u\n",
@@ -600,6 +602,23 @@ static void ath12k_dp_htt_mlo_peer_map_handler(struct ath12k_base *ab,
ath12k_dbg(ab, ATH12K_DBG_DP_HTT, "htt mlo peer map peer %pM id %u\n",
peer_addr, peer_id);
+
+ /*
+ * Fix up the dp_peer entry created with ATH12K_MLO_PEER_ID_PENDING
+ * earlier; on chips with host_alloc_ml_id == false this is the only
+ * point at which the host learns the firmware-assigned ID. Chips
+ * that allocate the ID on the host also receive this event but the
+ * firmware-reported ID matches the host-allocated one, so there is
+ * nothing to fix up.
+ */
+ if (!ab->hw_params->host_alloc_ml_id) {
+ ret = ath12k_dp_peer_fixup_peer_id(ab, peer_addr,
+ peer_id);
+ if (ret)
+ ath12k_warn(ab,
+ "failed to fix up peer id %u for dp peer %pM: %d\n",
+ peer_id, peer_addr, ret);
+ }
}
void ath12k_dp_htt_htc_t2h_msg_handler(struct ath12k_base *ab,
diff --git a/drivers/net/wireless/ath/ath12k/dp_peer.c b/drivers/net/wireless/ath/ath12k/dp_peer.c
index 2a2eae194007..09142dcb74f9 100644
--- a/drivers/net/wireless/ath/ath12k/dp_peer.c
+++ b/drivers/net/wireless/ath/ath12k/dp_peer.c
@@ -695,3 +695,55 @@ void ath12k_dp_link_peer_reset_rx_stats(struct ath12k_dp *dp, const u8 *addr)
if (rx_stats)
memset(rx_stats, 0, sizeof(*rx_stats));
}
+
+int ath12k_dp_peer_fixup_peer_id(struct ath12k_base *ab,
+ const u8 *peer_addr, u16 peer_id)
+{
+ struct ath12k_dp_link_peer *link_peer;
+ struct ath12k_dp_peer *dp_peer = NULL;
+ struct ath12k_hw_group *ag = ab->ag;
+ struct ath12k_dp_hw *dp_hw = NULL;
+ struct ath12k_hw *ah;
+ int i;
+
+ if (peer_id >= (ATH12K_PEER_ML_ID_VALID | ATH12K_MAX_MLO_PEERS))
+ return -EINVAL;
+
+ for (i = 0; i < ag->num_hw; i++) {
+ ah = ag->ah[i];
+ if (!ah)
+ continue;
+
+ spin_lock_bh(&ah->dp_hw.peer_lock);
+ dp_peer = ath12k_dp_peer_find_by_addr(&ah->dp_hw,
+ (u8 *)peer_addr);
+ if (dp_peer) {
+ dp_hw = &ah->dp_hw;
+ break;
+ }
+ spin_unlock_bh(&ah->dp_hw.peer_lock);
+ }
+
+ if (!dp_peer)
+ return -ENOENT;
+
+ /* dp_hw->peer_lock is held */
+
+ dp_peer->peer_id = peer_id;
+ rcu_assign_pointer(dp_hw->dp_peers[peer_id], dp_peer);
+
+ for (i = 0; i < ATH12K_NUM_MAX_LINKS; i++) {
+ link_peer = rcu_dereference_protected(dp_peer->link_peers[i],
+ lockdep_is_held(&dp_hw->peer_lock));
+ if (link_peer)
+ link_peer->ml_id = peer_id;
+ }
+
+ ath12k_sta_to_ahsta(dp_peer->sta)->ml_peer_id = peer_id;
+
+ spin_unlock_bh(&dp_hw->peer_lock);
+
+ complete(&ah->peer_ml_id_done);
+
+ return 0;
+}
diff --git a/drivers/net/wireless/ath/ath12k/dp_peer.h b/drivers/net/wireless/ath/ath12k/dp_peer.h
index f5067e66f1e1..9842671b5475 100644
--- a/drivers/net/wireless/ath/ath12k/dp_peer.h
+++ b/drivers/net/wireless/ath/ath12k/dp_peer.h
@@ -180,4 +180,6 @@ struct ath12k_dp_peer *ath12k_dp_peer_find_by_peerid(struct ath12k_pdev_dp *dp_p
struct ath12k_dp_link_peer *
ath12k_dp_link_peer_find_by_peerid(struct ath12k_pdev_dp *dp_pdev, u16 peer_id);
void ath12k_dp_link_peer_free(struct ath12k_dp_link_peer *peer);
+int ath12k_dp_peer_fixup_peer_id(struct ath12k_base *ab, const u8 *peer_addr,
+ u16 peer_id);
#endif
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index 818eb3aa919e..ae874114dc51 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -3855,9 +3855,11 @@ static u32 ath12k_mac_ieee80211_sta_bw_to_wmi(struct ath12k *ar,
static int ath12k_mac_peer_assoc(struct ath12k *ar,
struct ath12k_wmi_peer_assoc_arg *peer_arg)
{
+ struct ath12k_hw *ah = ath12k_ar_to_ah(ar);
int ret;
reinit_completion(&ar->peer_assoc_done);
+ reinit_completion(&ah->peer_ml_id_done);
ret = ath12k_wmi_send_peer_assoc_cmd(ar, peer_arg);
if (ret) {
@@ -3872,6 +3874,27 @@ static int ath12k_mac_peer_assoc(struct ath12k *ar,
return -ETIMEDOUT;
}
+ /*
+ * For devices where the firmware allocates the MLD peer ID, the host
+ * learns the real ID only from the MLO_RX_PEER_MAP HTT event, which is
+ * handled in a softirq (BH workqueue) context that cannot take the
+ * wiphy lock. Block here, while still holding the wiphy lock, until
+ * that event has fixed up the ID. This serialises the fixup against
+ * all other wiphy-locked ml_peer_id accesses.
+ *
+ * The firmware sends the event only once, in response to the assoc-link
+ * peer assoc, so block only for that link.
+ */
+ if (!ah->host_alloc_ml_id &&
+ peer_arg->is_assoc &&
+ peer_arg->ml.enabled &&
+ peer_arg->ml.assoc_link &&
+ !wait_for_completion_timeout(&ah->peer_ml_id_done, 1 * HZ)) {
+ ath12k_warn(ar->ab, "failed to get MLO peer map event for %pM vdev %i\n",
+ peer_arg->peer_mac, peer_arg->vdev_id);
+ return -ETIMEDOUT;
+ }
+
return 0;
}
@@ -15332,6 +15355,7 @@ static struct ath12k_hw *ath12k_mac_hw_allocate(struct ath12k_hw_group *ag,
ah->num_radio = num_pdev_map;
mutex_init(&ah->hw_mutex);
+ init_completion(&ah->peer_ml_id_done);
spin_lock_init(&ah->dp_hw.peer_lock);
INIT_LIST_HEAD(&ah->dp_hw.dp_peers_list);
--
2.25.1
^ permalink raw reply related
* [PATCH ath-current 7/8] wifi: ath12k: defer dp_peer registration when firmware allocates MLD peer ID
From: Baochen Qiang @ 2026-07-13 7:33 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, ath12k, Baochen Qiang
In-Reply-To: <20260713-ath12k-fw-allocated-ml-peer-id-v1-0-d0a2a1a519eb@oss.qualcomm.com>
For chips with host_alloc_ml_id=true (QCN9274 etc.), the host allocates
the MLD peer ID up front; ath12k_dp_peer_create() publishes the dp_peer
into dp_hw->dp_peers[] using that ID immediately. WCN7850/QCC2072 does
not work that way: the firmware picks the ID and only tells the host
afterwards via HTT_T2H_MSG_TYPE_MLO_RX_PEER_MAP, so the publication has
to be delayed until the event arrives.
Introduce ATH12K_MLO_PEER_ID_PENDING (0xFFFE) as a sentinel for "is_mlo,
but ID not yet known". On the firmware-allocates path:
- ath12k_mac_op_sta_state(NOTEXIST->NONE) skips ath12k_peer_ml_alloc()
and stores PENDING in ahsta->ml_peer_id and dp_params.peer_id;
- ath12k_dp_peer_create() skips dp_peer registration until a real ID is
known;
- ath12k_peer_create() leaves peer->ml_id at INVALID so consumer sites
do not treat PENDING as a real ID;
- ath12k_peer_ml_free() and ath12k_mac_dp_peer_cleanup() skip the
dp_peers[] write and the free_ml_peer_id_map clear when
host_alloc_ml_id is false or the ID is still PENDING.
The HTT handler change that resolves the PENDING ID is added in a
follow-up patch.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/core.h | 1 +
drivers/net/wireless/ath/ath12k/dp_peer.c | 23 +++++++++++++++--------
drivers/net/wireless/ath/ath12k/mac.c | 22 ++++++++++++++++------
drivers/net/wireless/ath/ath12k/peer.c | 20 +++++++++++++++++---
4 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
index 1f56474efbea..8769b41f5db5 100644
--- a/drivers/net/wireless/ath/ath12k/core.h
+++ b/drivers/net/wireless/ath/ath12k/core.h
@@ -72,6 +72,7 @@
#define ATH12K_MAX_MLO_PEERS 256
#define ATH12K_MLO_PEER_ID_INVALID 0xFFFF
+#define ATH12K_MLO_PEER_ID_PENDING 0xFFFE
#define ATH12K_INVALID_RSSI_FULL -1
#define ATH12K_INVALID_RSSI_EMPTY -128
diff --git a/drivers/net/wireless/ath/ath12k/dp_peer.c b/drivers/net/wireless/ath/ath12k/dp_peer.c
index 47d009a0d61f..2a2eae194007 100644
--- a/drivers/net/wireless/ath/ath12k/dp_peer.c
+++ b/drivers/net/wireless/ath/ath12k/dp_peer.c
@@ -472,7 +472,9 @@ int ath12k_dp_peer_create(struct ath12k_dp_hw *dp_hw, u8 *addr,
dp_peer->is_mlo = params->is_mlo;
/*
- * For MLO client, the host assigns the ML peer ID, so set peer_id in dp_peer
+ * For MLO client, the ML peer ID, either known or PENDING, needs to be
+ * initialized here since the following logic depends on it.
+ *
* For non-MLO client, host gets link peer ID from firmware and will be
* assigned at the time of link peer creation
*/
@@ -488,13 +490,17 @@ int ath12k_dp_peer_create(struct ath12k_dp_hw *dp_hw, u8 *addr,
list_add(&dp_peer->list, &dp_hw->dp_peers_list);
/*
- * For MLO client, the peer_id for ath12k_dp_peer is allocated by host
- * and that peer_id is known at this point, and hence this ath12k_dp_peer
- * can be added to the RCU table using the peer_id.
- * For non-MLO client, this addition to RCU table shall be done at the
- * time of assignment of ath12k_dp_link_peer to ath12k_dp_peer.
+ * For an MLO client whose ML peer ID is allocated by the host, the
+ * peer_id is known here and the dp_peer can be added to the RCU
+ * table using it. For an MLO client on chips where the firmware
+ * allocates the ID, peer_id is ATH12K_MLO_PEER_ID_PENDING and the
+ * RCU table publish is deferred to the
+ * HTT_T2H_MSG_TYPE_MLO_RX_PEER_MAP handler. For a non-MLO client
+ * the publish happens later, at the time of assignment of
+ * ath12k_dp_link_peer to ath12k_dp_peer.
*/
- if (dp_peer->is_mlo)
+ if (dp_peer->is_mlo &&
+ dp_peer->peer_id != ATH12K_MLO_PEER_ID_PENDING)
rcu_assign_pointer(dp_hw->dp_peers[dp_peer->peer_id], dp_peer);
spin_unlock_bh(&dp_hw->peer_lock);
@@ -515,7 +521,8 @@ void ath12k_dp_peer_delete(struct ath12k_dp_hw *dp_hw, u8 *addr,
return;
}
- if (dp_peer->is_mlo)
+ if (dp_peer->is_mlo &&
+ dp_peer->peer_id != ATH12K_MLO_PEER_ID_PENDING)
rcu_assign_pointer(dp_hw->dp_peers[dp_peer->peer_id], NULL);
list_del(&dp_peer->list);
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index 8cd5e9b15db5..818eb3aa919e 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -1285,7 +1285,9 @@ void ath12k_mac_dp_peer_cleanup(struct ath12k_hw *ah)
spin_lock_bh(&dp_hw->peer_lock);
list_for_each_entry_safe(dp_peer, tmp, &dp_hw->dp_peers_list, list) {
if (dp_peer->is_mlo) {
- rcu_assign_pointer(dp_hw->dp_peers[dp_peer->peer_id], NULL);
+ if (dp_peer->peer_id != ATH12K_MLO_PEER_ID_PENDING)
+ rcu_assign_pointer(dp_hw->dp_peers[dp_peer->peer_id],
+ NULL);
ath12k_peer_ml_free(ah, ath12k_sta_to_ahsta(dp_peer->sta));
}
@@ -7746,11 +7748,19 @@ int ath12k_mac_op_sta_state(struct ieee80211_hw *hw,
/* ML sta */
if (sta->mlo && !ahsta->links_map &&
(hweight16(sta->valid_links) == 1)) {
- ahsta->ml_peer_id = ath12k_peer_ml_alloc(ah);
- if (ahsta->ml_peer_id == ATH12K_MLO_PEER_ID_INVALID) {
- ath12k_hw_warn(ah, "unable to allocate ML peer id for sta %pM",
- sta->addr);
- goto exit;
+ if (ah->host_alloc_ml_id) {
+ ahsta->ml_peer_id = ath12k_peer_ml_alloc(ah);
+ if (ahsta->ml_peer_id == ATH12K_MLO_PEER_ID_INVALID) {
+ ath12k_hw_warn(ah, "unable to allocate ML peer id for sta %pM",
+ sta->addr);
+ goto exit;
+ }
+ } else {
+ /*
+ * firmware allocates the ML peer ID and notifies
+ * the host via HTT_T2H_MSG_TYPE_MLO_RX_PEER_MAP
+ */
+ ahsta->ml_peer_id = ATH12K_MLO_PEER_ID_PENDING;
}
dp_params.is_mlo = true;
diff --git a/drivers/net/wireless/ath/ath12k/peer.c b/drivers/net/wireless/ath/ath12k/peer.c
index ae93731b4177..25e4b79f11d6 100644
--- a/drivers/net/wireless/ath/ath12k/peer.c
+++ b/drivers/net/wireless/ath/ath12k/peer.c
@@ -230,7 +230,16 @@ int ath12k_peer_create(struct ath12k *ar, struct ath12k_link_vif *arvif,
/* Fill ML info into created peer */
if (sta->mlo) {
ml_peer_id = ahsta->ml_peer_id;
- peer->ml_id = ml_peer_id;
+ /*
+ * For chips where firmware allocates the ML peer ID,
+ * ml_peer_id is ATH12K_MLO_PEER_ID_PENDING here. The
+ * MLO_RX_PEER_MAP HTT event handler fixes up
+ * peer->ml_id once the ID is known.
+ */
+ if (ml_peer_id == ATH12K_MLO_PEER_ID_PENDING)
+ peer->ml_id = ATH12K_MLO_PEER_ID_INVALID;
+ else
+ peer->ml_id = ml_peer_id;
ether_addr_copy(peer->ml_addr, sta->addr);
/* the assoc link is considered primary for now */
@@ -285,8 +294,13 @@ void ath12k_peer_ml_free(struct ath12k_hw *ah, struct ath12k_sta *ahsta)
{
lockdep_assert_wiphy(ah->hw->wiphy);
- if (ahsta->ml_peer_id <
- (ATH12K_MAX_MLO_PEERS | ATH12K_PEER_ML_ID_VALID))
+ /*
+ * Only devices that allocate the ID on the host own a slot in
+ * free_ml_peer_id_map.
+ */
+ if (ah->host_alloc_ml_id &&
+ (ahsta->ml_peer_id <
+ (ATH12K_MAX_MLO_PEERS | ATH12K_PEER_ML_ID_VALID)))
clear_bit(ahsta->ml_peer_id & ~ATH12K_PEER_ML_ID_VALID,
ah->free_ml_peer_id_map);
ahsta->ml_peer_id = ATH12K_MLO_PEER_ID_INVALID;
--
2.25.1
^ permalink raw reply related
* [PATCH ath-current 6/8] wifi: ath12k: do not advertise MLD peer ID for firmware-allocate devices
From: Baochen Qiang @ 2026-07-13 7:33 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, ath12k, Baochen Qiang
In-Reply-To: <20260713-ath12k-fw-allocated-ml-peer-id-v1-0-d0a2a1a519eb@oss.qualcomm.com>
ath12k_peer_assoc_h_mlo() unconditionally sets ml->peer_id_valid and copies
ahsta->ml_peer_id (with the ATH12K_PEER_ML_ID_VALID bookkeeping bit masked
off) into the WMI_PEER_ASSOC_CMDID ML params, which causes
ath12k_wmi_send_peer_assoc_cmd() to set ATH12K_WMI_FLAG_MLO_PEER_ID_VALID.
This needs to be gated on chips where the firmware allocates the MLD peer
ID:
- WCN7850/QCC2072 firmware always picks the ID itself and does not honor
a host-supplied one, so the value would be silently ignored anyway;
- QCC2072 firmware additionally crashes during MLO disconnect when
ATH12K_WMI_FLAG_MLO_PEER_ID_VALID was set in the preceding peer assoc,
so the bit must not be sent at all.
Branch on ah->host_alloc_ml_id:
- When true (QCN9274 etc.), behavior is unchanged: peer_id_valid is set
and the raw ahsta->ml_peer_id (without the VALID bit) is sent down.
- When false (WCN7850, QCC2072), peer_id_valid stays unset and
ml_peer_id is sent as 0. The firmware ignores both fields and reports
the ID it allocated through HTT_T2H_MSG_TYPE_MLO_RX_PEER_MAP.
The early-return on ahsta->ml_peer_id == ATH12K_MLO_PEER_ID_INVALID only
applies on the host-alloc path, since on the firmware-alloc path the value
is ATH12K_MLO_PEER_ID_PENDING here, not INVALID.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/mac.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index 9e5fcbf8c730..8cd5e9b15db5 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -3529,11 +3529,16 @@ static void ath12k_peer_assoc_h_mlo(struct ath12k_link_sta *arsta,
struct ath12k_sta *ahsta = arsta->ahsta;
struct ath12k_link_sta *arsta_p;
struct ath12k_link_vif *arvif;
+ struct ath12k_hw *ah = arsta->arvif->ar->ah;
unsigned long links;
u8 link_id;
int i;
- if (!sta->mlo || ahsta->ml_peer_id == ATH12K_MLO_PEER_ID_INVALID)
+ if (!sta->mlo)
+ return;
+
+ if (ah->host_alloc_ml_id &&
+ ahsta->ml_peer_id == ATH12K_MLO_PEER_ID_INVALID)
return;
ml->enabled = true;
@@ -3541,16 +3546,25 @@ static void ath12k_peer_assoc_h_mlo(struct ath12k_link_sta *arsta,
/* For now considering the primary umac based on assoc link */
ml->primary_umac = arsta->is_assoc_link;
- ml->peer_id_valid = true;
+ /*
+ * Only chips that allocate the MLD peer ID on the host send a valid
+ * ml_peer_id in WMI_PEER_ASSOC_CMDID. For chips where the firmware
+ * picks the ID, leave peer_id_valid false to avoid unexpected issues.
+ */
+ ml->peer_id_valid = ah->host_alloc_ml_id;
ml->logical_link_idx_valid = true;
ether_addr_copy(ml->mld_addr, sta->addr);
ml->logical_link_idx = arsta->link_idx;
/*
* WMI_MLO_PEER_ASSOC_PARAMS expects the raw ML peer ID without
- * the host-side ATH12K_PEER_ML_ID_VALID bookkeeping bit.
+ * the host-side ATH12K_PEER_ML_ID_VALID bookkeeping bit. For chips
+ * where the firmware allocates the ID, the field is unused (the
+ * firmware always allocates regardless of the value here); send 0
+ * to make that intent explicit.
*/
- ml->ml_peer_id = ahsta->ml_peer_id & ~ATH12K_PEER_ML_ID_VALID;
+ ml->ml_peer_id = ah->host_alloc_ml_id ?
+ (ahsta->ml_peer_id & ~ATH12K_PEER_ML_ID_VALID) : 0;
ml->ieee_link_id = arsta->link_id;
ml->num_partner_links = 0;
ml->eml_cap = sta->eml_cap;
--
2.25.1
^ permalink raw reply related
* [PATCH ath-current 5/8] wifi: ath12k: introduce host_alloc_ml_id hardware parameter
From: Baochen Qiang @ 2026-07-13 7:33 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, ath12k, Baochen Qiang
In-Reply-To: <20260713-ath12k-fw-allocated-ml-peer-id-v1-0-d0a2a1a519eb@oss.qualcomm.com>
Different ath12k devices diverge on who allocates MLD peer id:
WCN7850/QCC2072 have the firmware allocate it and notify the host via
HTT_T2H_MSG_TYPE_MLO_RX_PEER_MAP event; While others let the host allocate
it and pass it down through WMI_PEER_ASSOC_CMDID with
ATH12K_WMI_FLAG_MLO_PEER_ID_VALID set.
Currently ath12k host allocates this ID and sends it to firmware by
default for all devices. This breaks WCN7850/QCC2072, because the host
maintained ID may be different from the firmware-allocated one.
Consequently data path may fail to find the dp peer and drop some received
packets. From user point of view, this results in bugs reported in [1] or
the 4-way handshake timeout issue.
Add host_alloc_ml_id flag to struct ath12k_hw_params (and a copy on struct
ath12k_hw for hot-path access) so subsequent patches can branch on it. Set
true for QCN9274/IPQ5332/IPQ5424, false for WCN7850/QCC2072. The flag will
be consumed by subsequent patches.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221039 # 1
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/core.h | 1 +
drivers/net/wireless/ath/ath12k/hw.h | 2 ++
drivers/net/wireless/ath/ath12k/mac.c | 17 ++++++++++++++++-
drivers/net/wireless/ath/ath12k/wifi7/hw.c | 12 ++++++++++++
4 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
index fc5127b5c1a3..1f56474efbea 100644
--- a/drivers/net/wireless/ath/ath12k/core.h
+++ b/drivers/net/wireless/ath/ath12k/core.h
@@ -793,6 +793,7 @@ struct ath12k_hw {
enum ath12k_hw_state state;
bool regd_updated;
bool use_6ghz_regd;
+ bool host_alloc_ml_id;
u8 num_radio;
diff --git a/drivers/net/wireless/ath/ath12k/hw.h b/drivers/net/wireless/ath/ath12k/hw.h
index d135b2936378..8091501cf742 100644
--- a/drivers/net/wireless/ath/ath12k/hw.h
+++ b/drivers/net/wireless/ath/ath12k/hw.h
@@ -232,6 +232,8 @@ struct ath12k_hw_params {
u32 max_client_dbs;
u32 max_client_dbs_sbs;
} client;
+
+ bool host_alloc_ml_id;
};
struct ath12k_hw_ops {
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index 7d0d7d5fbf53..9e5fcbf8c730 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -15382,8 +15382,9 @@ int ath12k_mac_allocate(struct ath12k_hw_group *ag)
int mac_id, device_id, total_radio, num_hw;
struct ath12k_base *ab;
struct ath12k_hw *ah;
- int ret, i, j;
+ bool conf = false;
u8 radio_per_hw;
+ int ret, i, j;
total_radio = 0;
for (i = 0; i < ag->num_devices; i++) {
@@ -15423,6 +15424,19 @@ int ath12k_mac_allocate(struct ath12k_hw_group *ag)
}
ab = ag->ab[device_id];
+
+ /*
+ * the assumption is all devices within an ah
+ * share the same host_alloc_ml_id configuration
+ */
+ if (j == 0) {
+ conf = ab->hw_params->host_alloc_ml_id;
+ } else if (conf != ab->hw_params->host_alloc_ml_id) {
+ ath12k_warn(ab, "inconsistent ML ID config within ah, device 0 uses %s allocated ID, while device %u doesn't\n",
+ conf ? "host" : "firmware", device_id);
+ goto err;
+ }
+
pdev_map[j].ab = ab;
pdev_map[j].pdev_idx = mac_id;
mac_id++;
@@ -15447,6 +15461,7 @@ int ath12k_mac_allocate(struct ath12k_hw_group *ag)
}
ah->dev = ab->dev;
+ ah->host_alloc_ml_id = conf;
ag->ah[i] = ah;
ag->num_hw++;
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hw.c b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
index e5bf9d218104..0c277f51d99c 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/hw.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
@@ -439,6 +439,8 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
.max_client_dbs = 128,
.max_client_dbs_sbs = 128,
},
+
+ .host_alloc_ml_id = true,
},
{
.name = "wcn7850 hw2.0",
@@ -530,6 +532,8 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
.max_client_dbs = 128,
.max_client_dbs_sbs = 128,
},
+
+ .host_alloc_ml_id = false,
},
{
.name = "qcn9274 hw2.0",
@@ -617,6 +621,8 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
.max_client_dbs = 128,
.max_client_dbs_sbs = 128,
},
+
+ .host_alloc_ml_id = true,
},
{
.name = "ipq5332 hw1.0",
@@ -697,6 +703,8 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
.max_client_dbs = 128,
.max_client_dbs_sbs = 128,
},
+
+ .host_alloc_ml_id = true,
},
{
.name = "qcc2072 hw1.0",
@@ -789,6 +797,8 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
.max_client_dbs = 128,
.max_client_dbs_sbs = 128,
},
+
+ .host_alloc_ml_id = false,
},
{
.name = "ipq5424 hw1.0",
@@ -873,6 +883,8 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
.max_client_dbs = 128,
.max_client_dbs_sbs = 128,
},
+
+ .host_alloc_ml_id = true,
},
};
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox