From: Luka Gejak <luka.gejak@linux.dev>
To: Alastair D'Silva <alastair@d-silva.org>
Cc: Ping-Ke Shih <pkshih@realtek.com>, Kalle Valo <kvalo@kernel.org>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Luka Gejak <luka.gejak@linux.dev>
Subject: Re: [PATCH v3 1/2] wifi: rtw88: sdio: Fix unhandled RX request interrupt storm
Date: Thu, 1 Oct 2026 06:02:12 +0000 [thread overview]
Message-ID: <20261001060213.24759-1-luka.gejak@linux.dev> (raw)
In-Reply-To: <20261001000303.3505264-2-alastair@d-silva.org>
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
next prev parent reply other threads:[~2026-10-01 6:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 0:03 [PATCH v3 0/2] wifi: rtw88: sdio: Fix interrupt storm on 3081 chips and split RX handling Alastair D'Silva
2026-10-01 0:03 ` [PATCH v3 1/2] wifi: rtw88: sdio: Fix unhandled RX request interrupt storm Alastair D'Silva
2026-10-01 6:02 ` Luka Gejak [this message]
2026-10-01 0:03 ` [PATCH v3 2/2] wifi: rtw88: sdio: Split rtw_sdio_rx_isr into 8051 and 3081 variants Alastair D'Silva
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261001060213.24759-1-luka.gejak@linux.dev \
--to=luka.gejak@linux.dev \
--cc=alastair@d-silva.org \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=pkshih@realtek.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®