Re: [PATCH v3 1/2] wifi: rtw88: sdio: Fix unhandled RX request interrupt storm

[Alastair D'Silva <alastair@d-silva.org>]

On Mon, 2026-10-05 at 03:35 +0000, Ping-Ke Shih wrote:
> Alastair D'Silva <alastair@d-silva.org> wrote:
> > 8051 and 3081 SDIO chipsets handle the REG_SDIO_HISR_RX_REQUEST status bit
> > differently:
> > 
> > - 8051-based chips (e.g. RTL8723BS, RTL8723CS, RTL8723DS):
> >   The hardware automatically clears REG_SDIO_HISR_RX_REQUEST once the RX
> >   buffer is empty. Software must not clear this bit, because the drain
> >   loop in rtw_sdio_rx_isr() re-reads REG_SDIO_HISR across iterations to
> >   decide whether more requests are pending. Clearing it in software
> >   terminates the loop after a single request, stranding the remainder of
> >   the FIFO. Additionally, RTL8723BS requires RTW_SDIO_HISR_CLEAR_MASK to
> >   avoid undefined bits causing resume storms.
> > 
> > - 3081-based chips (e.g. RTL8821CS, RTL8822CS):
> >   The hardware does not automatically clear REG_SDIO_HISR_RX_REQUEST when
> >   the RX buffer is empty. Masking this bit out in software before writing
> >   back to HISR prevented it from ever being acknowledged in hardware,
> >   trapping the CPU core in an infinite interrupt storm loop that starved
> >   RCU and locked up the system. Furthermore, on 3081 chips the physical
> >   RX FIFO capacity is at most 24 KB (16 KB on RTL8821CS, 24 KB on
> >   RTL8822CS), which is well within the 64 KB loop budget.
> > 
> > As the number of architecture-specific special cases has grown (16-bit vs
> > 32-bit register widths, differing HISR writeback timing, synthetic loop
> > flags, and RTL8723BS resume masking), attempting to accommodate both
> > architectures within a single monolithic handler has become fragile and
> > prone to cross-architecture regressions.
> > 
> > Resolve this by making rtw_sdio_handle_interrupt() a dispatcher with
> > separate paths for 8051 and 3081:
> > 
> > 1. 8051 chips preserve the existing unmasked writeback behavior, leaving
> >    REG_SDIO_HISR_RX_REQUEST for hardware to drop and respecting
> >    RTW_SDIO_HISR_CLEAR_MASK on RTL8723BS.
> > 2. 3081 chips adopt the interrupt masking pattern: disable HIMR,
> >    acknowledge pending status bits in HISR via W1C, service the pending
> >    events, and re-enable HIMR. Any packet arriving during servicing
> >    latches REG_SDIO_HISR_RX_REQUEST in hardware and re-asserts the IRQ line
> >    once unmasked.
> > 
> > Splitting into separate handlers isolates these quirks cleanly and
> > simplifies future maintenance.
> > 
> > Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
> 
> At this moment, did it support 3081-seris already?
> I feel this tag is too serious. 
> 

Yes, 3081 chipsets were actually the original devices enabled in that initial SDIO series.

In commit 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets"), the
SDIO HCI was introduced along with hisr &= ~REG_SDIO_HISR_RX_REQUEST;. Later in that exact same 10-
patch series (merged into v6.4-rc1), the following SDIO devices were added:

Commit 095e62dd7427: RTL8822BS (3081)
Commit 6fdacb78f799: RTL8822CS (3081)
Commit b2a777d68434: RTL8821CS (3081)

No 8051 SDIO chipsets existed in rtw88 at that time (RTL8723DS was added in v6.5, and RTL8723BS much
later).

That said, if you prefer attributing the regression to the device enablement commit rather than the
core SDIO HCI commit, we can change the tag to: Fixes: b2a777d68434 ("wifi: rtw88: Add support for
the SDIO based RTL8821CS chipset")

Both commits landed in v6.4-rc1, so the stable tree targeting remains identical. Please let us know
your preference.

-- 
Alastair D'Silva