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

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

[Alastair D'Silva]

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")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
---
v3:
- Rebased on rtw-next.
- Preserved 8051 interrupt handling behavior and RTW_SDIO_HISR_CLEAR_MASK
  by splitting rtw_sdio_handle_interrupt() into separate 8051 and 3081
  dispatch routines (thanks Luka Gejak for the review and analysis).
- Moved hisr reading and early exit on spurious IRQ into the dispatcher.
- Verified on Allwinner H618 (Mellow Fly-C5) with RTL8821CS under Linux 7.2:
  * Baseline (0 us delay): 36.7 Mbps UDP (0.0% loss), 35.1 Mbps TCP, 0 RCU stalls.
    HIMR toggle overhead is 34.2 us (10.3% of ISR duration).
  * Injected delays (500 us, 2 ms, 10 ms): zero packet loss (0.0%), masked
    arrivals verified latched and re-asserted upon unmasking (7.5% -> 16.5%
    of IRQs catching masked packet arrivals).
- Added Assisted-by tag per Documentation/process/coding-assistants.rst.

v2:
- Reworked interrupt acknowledgment to use HIMR masking
  (rtw_sdio_disable_interrupt / rtw_sdio_enable_interrupt) to avoid races
  between reading RX0_REQ_LEN and clearing HISR.

v1:
- https://lore.kernel.org/linux-wireless/20260921085502.123456-1-alastair@d-silva.org/

 drivers/net/wireless/realtek/rtw88/sdio.c | 51 +++++++++++++++++------
 1 file changed, 38 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtw88/sdio.c b/drivers/net/wireless/realtek/rtw88/sdio.c
index dc2fd0f8f9ff..63d62242ac1e 100644
--- a/drivers/net/wireless/realtek/rtw88/sdio.c
+++ b/drivers/net/wireless/realtek/rtw88/sdio.c
@@ -1455,20 +1455,8 @@ static void rtw_sdio_rx_isr(struct rtw_dev *rtwdev)
 	} while (total_rx_bytes < SZ_64K && hisr & REG_SDIO_HISR_RX_REQUEST);
 }
 
-static void rtw_sdio_handle_interrupt(struct sdio_func *sdio_func)
+static void rtw_sdio_handle_interrupt_8051(struct rtw_dev *rtwdev, u32 hisr)
 {
-	struct ieee80211_hw *hw = sdio_get_drvdata(sdio_func);
-	struct rtw_sdio *rtwsdio;
-	struct rtw_dev *rtwdev;
-	u32 hisr;
-
-	rtwdev = hw->priv;
-	rtwsdio = (struct rtw_sdio *)rtwdev->priv;
-
-	rtwsdio->irq_thread = current;
-
-	hisr = rtw_read32(rtwdev, REG_SDIO_HISR);
-
 	if (hisr & REG_SDIO_HISR_TXERR)
 		rtw_sdio_tx_err_isr(rtwdev);
 	if (hisr & REG_SDIO_HISR_RX_REQUEST) {
@@ -1485,7 +1473,44 @@ static void rtw_sdio_handle_interrupt(struct sdio_func *sdio_func)
 		hisr &= RTW_SDIO_HISR_CLEAR_MASK;
 
 	rtw_write32(rtwdev, REG_SDIO_HISR, hisr);
+}
+
+static void rtw_sdio_handle_interrupt_3081(struct rtw_dev *rtwdev, u32 hisr)
+{
+	rtw_sdio_disable_interrupt(rtwdev);
+	rtw_write32(rtwdev, REG_SDIO_HISR, hisr);
+
+	if (hisr & REG_SDIO_HISR_TXERR)
+		rtw_sdio_tx_err_isr(rtwdev);
+	if (hisr & REG_SDIO_HISR_RX_REQUEST)
+		rtw_sdio_rx_isr(rtwdev);
+
+	/* Unmasking HIMR re-asserts the IRQ line if new packets arrived */
+	rtw_sdio_enable_interrupt(rtwdev);
+}
+
+static void rtw_sdio_handle_interrupt(struct sdio_func *sdio_func)
+{
+	struct ieee80211_hw *hw = sdio_get_drvdata(sdio_func);
+	struct rtw_sdio *rtwsdio;
+	struct rtw_dev *rtwdev;
+	u32 hisr;
+
+	rtwdev = hw->priv;
+	rtwsdio = (struct rtw_sdio *)rtwdev->priv;
+
+	rtwsdio->irq_thread = current;
+
+	hisr = rtw_read32(rtwdev, REG_SDIO_HISR);
+	if (!hisr)
+		goto out;
+
+	if (rtw_chip_wcpu_8051(rtwdev))
+		rtw_sdio_handle_interrupt_8051(rtwdev, hisr);
+	else
+		rtw_sdio_handle_interrupt_3081(rtwdev, hisr);
 
+out:
 	rtwsdio->irq_thread = NULL;
 }
 
-- 
2.53.0

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

[Luka Gejak]

Hi Alastair,

The split looks good to me.

One issue with acknowledging the request up front:

> +	rtw_sdio_disable_interrupt(rtwdev);
> +	rtw_write32(rtwdev, REG_SDIO_HISR, hisr);

When dev_alloc_skb() fails, rtw_sdio_rxfifo_recv() returns without
reading the port:

	skb = dev_alloc_skb(bufsz);
	if (!skb)
	  return;

but the loop counts the bytes anyway:

		rtw_sdio_rxfifo_recv(rtwdev, rx_len);

		total_rx_bytes += rx_len;

so a few failed reads burn the 64K budget and the loop exits with the
FIFO still full. The request is already cleared by then, and only a new
packet sets it again, which may never come if the FIFO is full and the
sender is paused. 8051 does not have this problem because it leaves the
bit to hardware. Can rtw_sdio_rxfifo_recv() report the failure, so the
loop can stop and retry instead? The read error just below the allocation
leaves the FIFO in the same state.

Same function, the enable at the end:

> +	/* Unmasking HIMR re-asserts the IRQ line if new packets arrived */
> +	rtw_sdio_enable_interrupt(rtwdev);

It also runs when the device has been stopped. ksdioirqd can still run a
handler that was signalled before rtw_sdio_stop() released the host, and
stop only writes HIMR as zero:

	static void rtw_sdio_stop(struct rtw_dev *rtwdev)
	{
		rtw_sdio_disable_interrupt(rtwdev);
	}

rtwsdio->irq_mask still has RX_REQUEST and CPWM1, so this puts the mask
back and arms the stopped device again. PCI clears rtwpci->running in its
stop path and only re-enables while it is still set:

	if (rtwpci->running)
		rtw_pci_enable_interrupt(rtwdev, rtwpci, rx);

Can you add something like that here?

Best regards,
Luka Gejak

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

[Ping-Ke Shih]

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. 

> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>

Acked-by: Ping-Ke Shih <pkshih@realtek.com>

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

[Luka Gejak]

October 5, 2026 at 05:35, "Ping-Ke Shih" <pkshih@realtek.com mailto:pkshih@realtek.com?to=%22Ping-Ke%20Shih%22%20%3Cpkshih%40realtek.com%3E > 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. 
> 
> > 
> > Cc: stable@vger.kernel.org
> >  Assisted-by: LLM
> >  Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> > 
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
>

Hi Ping-Ke,
I think you missed my review at [1].

Best regards,
Luka Gejak

[1]:https://lore.kernel.org/all/20261001060213.24759-1-luka.gejak@linux.dev/

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

[Ping-Ke Shih]

Luka Gejak <luka.gejak@linux.dev> wrote:
> I think you missed my review at [1].
> 
> [1]:https://lore.kernel.org/all/20261001060213.24759-1-luka.gejak@linux.dev/

I feel like that might be existing issue? If so, use other patches to fix
them. 

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

[Alastair D'Silva]

On Mon, 2026-10-05 at 05:30 +0000, Ping-Ke Shih wrote:
> Luka Gejak <luka.gejak@linux.dev> wrote:
> > I think you missed my review at [1].
> > 
> > [1]:https://lore.kernel.org/all/20261001060213.24759-1-luka.gejak@linux.dev/
> 
> I feel like that might be existing issue? If so, use other patches to fix
> them. 
> 

Yes, it's an existing issue - I can submit that in a separate series if you prefer.

-- 
Alastair D'Silva
0493 18 5566

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

[Ping-Ke Shih]

Alastair D'Silva <alastair@d-silva.org> wrote:
> On Mon, 2026-10-05 at 05:30 +0000, Ping-Ke Shih wrote:
> > Luka Gejak <luka.gejak@linux.dev> wrote:
> > > I think you missed my review at [1].
> > >
> > > [1]:https://lore.kernel.org/all/20261001060213.24759-1-luka.gejak@linux.dev/
> >
> > I feel like that might be existing issue? If so, use other patches to fix
> > them.
> >
> 
> Yes, it's an existing issue - I can submit that in a separate series if you prefer.

Yes, please. 

If this series isn't hurry, please put into the same series. 
(I'd send pull-request for current -next cycle this week.)

Ping-Ke

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

[Alastair D'Silva]

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

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

[Ping-Ke Shih]

Alastair D'Silva <alastair@d-silva.org> wrote:
> Both commits landed in v6.4-rc1, so the stable tree targeting remains identical. Please let us know
> your preference.

Okay. Keep the Fixes tag.