mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 v2] wifi: rtw88: sdio: Fix unhandled RX request interrupt storm
Date: Wed, 30 Sep 2026 10:06:29 +0000	[thread overview]
Message-ID: <20260930100629.14270-1-luka.gejak@linux.dev> (raw)
In-Reply-To: <20260930090714.2779699-1-alastair@d-silva.org>

Hi Alastair,

This breaks the drain loop on the 8051 parts. The early write clears
REG_SDIO_HISR_RX_REQUEST before rtw_sdio_rx_isr() runs, but the 8051 branch
of the loop uses that bit to decide whether another request is pending:

> +	rtw_sdio_disable_interrupt(rtwdev);
> +	rtw_write32(rtwdev, REG_SDIO_HISR, hisr);
> [...]
> +	if (hisr & REG_SDIO_HISR_RX_REQUEST)
>  		rtw_sdio_rx_isr(rtwdev);

		if (rtw_chip_wcpu_8051(rtwdev)) {
			hisr = rtw_read32(rtwdev, REG_SDIO_HISR);
		} else {
			hisr = REG_SDIO_HISR_RX_REQUEST;
		}
	} while (total_rx_bytes < SZ_64K && hisr & REG_SDIO_HISR_RX_REQUEST);

In the v1 thread Ping-Ke relayed that the hardware clears the bit once the
RX buffer is empty, and that a software clear means no new interrupt unless
a new packet arrives. So the first re-read after the write returns 0, the
loop stops after one request, and the rest of the FIFO waits for the next
packet.

The 8821CS cannot show this, since 3081 parts never read HISR there.
RTL8723CS, RTL8723DS and the RTL8723BS once its glue lands are the 8051
SDIO parts, so please run the test on one of those, or leave RX_REQUEST out
of the early write and let the hardware drop it.

This also needs a rebase for rtw-next. The 8723BS mask sits between this
block and the old write:

	if (rtw_is_8723bs(rtwdev))
		hisr &= RTW_SDIO_HISR_CLEAR_MASK;

	rtw_write32(rtwdev, REG_SDIO_HISR, hisr);

Moving the write up as posted puts the raw value back, undefined bits
included, which is the resume storm on 8723BS that the mask exists to
avoid.

One smaller thing, the early write also consumes anything already queued
when the handler starts, so what the 64K budget leaves behind waits for the
next packet too, on 3081 as well.

Best regards,
Luka Gejak

      parent reply	other threads:[~2026-09-30 10:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30  9:07 Alastair D'Silva
2026-09-30  9:18 ` Alastair D'Silva
2026-09-30 10:06 ` Luka Gejak [this message]

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=20260930100629.14270-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®