This series fixes several performance bottlenecks and correctness
issues in both brcmfmac (PCIe/SDIO) and brcmsmac drivers.

Changes since v3:
 - cfg80211.c: Removed spurious double blank line flagged by
   checkpatch --strict.
 - All commit messages rewritten to follow kernel standards:
   explain the problem symptom first, then the solution, add
   Fixes: tags where applicable, wrap lines at 72 chars.
 - pcie.c: Added Fixes: tag referencing the original PCIe commit.

Changes since v2:
 - core.c: Add skb_cow_head() before skb_push() to prevent a
   kernel panic when skb arrives with zero headroom.
 - cfg80211.c: Fix PMKID V2 shadow counter corruption bug.

Changes since v1:
 - Correct author and Signed-off-by to chanelshivesh@gmail.com.

Patch overview:
 1/8 flowring: Replace O(N) blocked-ring scan with atomic counter.
 2/8 sdio: Coalesce N+1 sdio_claim_host() pairs in rxglom path.
 3/8 core: Fix skb_push() panic; populate radiotap RSSI field.
 4/8 cfg80211: Implement PMKID_V2; fix shadow counter overwrite;
     replace mdelay() with usleep_range().
 5/8 msgbuf: Fix silent TX stall; increase NR_TX_PKTIDS to 4096.
 6/8 pcie: Replace msleep() with usleep_range() + backoff.
 7/8 fwsignal: Document safe no-op for duplicate MAC handle ADD.
 8/8 brcmsmac/ampdu: Reference IEEE 802.11n TID requirement.

Shivesh (8):
  wifi: brcmfmac: flowring: replace O(N) blocked-ring scan with atomic
    counter
  wifi: brcmfmac: sdio: coalesce sdio_claim_host calls in rxglom path
  wifi: brcmfmac: core: fix missing headroom check and populate radiotap
    RSSI
  wifi: brcmfmac: cfg80211: implement PMKID_V2 and fix brcmf_delay
    busy-wait
  wifi: brcmfmac: msgbuf: fix TX stall and tune buffer/threshold
    constants
  wifi: brcmfmac: pcie: replace msleep polling with usleep_range and
    backoff
  wifi: brcmfmac: fwsignal: document safe no-op for duplicate MAC handle
    ADD
  wifi: brcmsmac: ampdu: document IEEE 802.11n TID requirement

 .../broadcom/brcm80211/brcmfmac/cfg80211.c    | 122 ++++++++++++++++--
 .../broadcom/brcm80211/brcmfmac/cfg80211.h    |   4 +-
 .../broadcom/brcm80211/brcmfmac/core.c        |  44 ++++---
 .../broadcom/brcm80211/brcmfmac/flowring.c    |  65 +++++++---
 .../broadcom/brcm80211/brcmfmac/flowring.h    |  18 +++
 .../broadcom/brcm80211/brcmfmac/fwsignal.c    |   4 +-
 .../broadcom/brcm80211/brcmfmac/msgbuf.c      |  69 ++++++++--
 .../broadcom/brcm80211/brcmfmac/pcie.c        |  66 ++++++++--
 .../broadcom/brcm80211/brcmfmac/sdio.c        |  62 +++++----
 .../broadcom/brcm80211/brcmsmac/ampdu.c       |  11 +-
 10 files changed, 374 insertions(+), 91 deletions(-)


base-commit: 5e0bcb4920bcb9e0ef6c03a91730fe45f643f3a4
-- 
2.53.0

On Fri, 31 Jul 2026 16:06:17 +0000, Shivesh <chanelshivesh@gmail.com> wrote:
> This series fixes several performance bottlenecks and correctness
> issues in both brcmfmac (PCIe/SDIO) and brcmsmac drivers.

Two blockers need to be fixed before any of this can be applied:

- 2/8: num++ was dropped from the subframe-parse loop. cnt is always 0
  on return, so rd->seq_num += cnt - 1 underflows to 255 (u8) on every
  successful glom receive, corrupting sequence-number tracking for all
  subsequent packets.

- 4/8: pmksa->fils_cache_id does not exist in struct cfg80211_pmksa;
  the correct field name is cache_id so this does not compile.

Beyond the blockers, please split the series into separate submissions:
1. Stability and correctness fixes (3/8, 5/8 TX-stall fix, 6/8 Fixes
   tagged part)
2. Performance improvements (1/8, 2/8, 5/8, 6/8 performance parts)
3. New functionality and comment-only patches (4/8 PMKID_V2,7/8, 8/8)

This makes it easier dealing with fixes that should go to stable trees.
For the stability series you can add Cc: stable@vger.kernel.org and a
Fixes: tag in the commit message.

Regarding patch 1/8: the patch also fixes a race where a ring state
changes RING_OPEN->RING_CLOSING while blocked causes a permanent
netif queue stop. The fix relies on the atomic counter so keeping them
together is fine, but this change is primarily a potential bug fix so
rephrase the subject, e.g. "fix blocked-ring race permanently stopping queue"

Finally, some of the commit messages seem to use LLM lingo so if there
was a coding assistent used please add an Assisted-by tag as required by
Documentation/process/coding-assistants.rst.

Regards,
Arend

On 02/08/2026 12:15, Arend van Spriel wrote:
> On Fri, 31 Jul 2026 16:06:17 +0000, Shivesh <chanelshivesh@gmail.com> wrote:
>> This series fixes several performance bottlenecks and correctness
>> issues in both brcmfmac (PCIe/SDIO) and brcmsmac drivers.
> 
> Two blockers need to be fixed before any of this can be applied:
> 
> - 2/8: num++ was dropped from the subframe-parse loop. cnt is always 0
>    on return, so rd->seq_num += cnt - 1 underflows to 255 (u8) on every
>    successful glom receive, corrupting sequence-number tracking for all
>    subsequent packets.
> 
> - 4/8: pmksa->fils_cache_id does not exist in struct cfg80211_pmksa;
>    the correct field name is cache_id so this does not compile.
> 
> Beyond the blockers, please split the series into separate submissions:
> 1. Stability and correctness fixes (3/8, 5/8 TX-stall fix, 6/8 Fixes
>     tagged part)
> 2. Performance improvements (1/8, 2/8, 5/8, 6/8 performance parts)
> 3. New functionality and comment-only patches (4/8 PMKID_V2,7/8, 8/8)
> 
> This makes it easier dealing with fixes that should go to stable trees.
> For the stability series you can add Cc: stable@vger.kernel.org and a
> Fixes: tag in the commit message.
> 
> Regarding patch 1/8: the patch also fixes a race where a ring state
> changes RING_OPEN->RING_CLOSING while blocked causes a permanent
> netif queue stop. The fix relies on the atomic counter so keeping them
> together is fine, but this change is primarily a potential bug fix so
> rephrase the subject, e.g. "fix blocked-ring race permanently stopping queue"
> 
> Finally, some of the commit messages seem to use LLM lingo so if there
> was a coding assistent used please add an Assisted-by tag as required by
> Documentation/process/coding-assistants.rst.

Some additional remarks. Have these patches all been tested and if so 
please add reference to the platform used. Especially for the 
performance improvements it would also be good to have some profiling 
information as to how much performance gain these patches provide.

Regards,
Arend