Linux wireless drivers development
 help / color / mirror / Atom feed
From: Ping-Ke Shih <pkshih@realtek.com>
To: Josef Schlehofer <pepe.schlehofer@gmail.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc: Mohammed Afifi <i.mafifi17@gmail.com>,
	Bitterblue Smith <rtl8821cerfe2@gmail.com>
Subject: RE: [PATCH rtw-next v5] wifi: rtw88: usb: Download the reserved page synchronously
Date: Tue, 13 Oct 2026 03:50:50 +0000	[thread overview]
Message-ID: <adc49955e3e24177b3e935617d80ed0a@realtek.com> (raw)
In-Reply-To: <20261013033737.6761-1-pepe.schlehofer@gmail.com>

Josef Schlehofer <pepe.schlehofer@gmail.com> wrote:
> From: Mohammed Afifi <i.mafifi17@gmail.com>
> 
> In AP mode the reserved page (which contains the beacon) is downloaded
> to the chip by rtw_fw_write_data_rsvd_page(). That function writes the
> data via rtw_hci_write_data_rsvd_page() and then immediately polls the
> hardware BCN_VALID bit to confirm the firmware accepted the beacon.
> 
> On USB, rtw_usb_write_data_rsvd_page() ends up in rtw_usb_write_port(),
> which submits the URB with usb_submit_urb() and returns as soon as the
> transfer is queued. The completion callback only frees the skb. As a
> result the BCN_VALID poll can run while the beacon is still in flight
> on the bus, and the poll times out even though the download itself is
> fine.
> 
> This shows up as:
> 
>   rtw_8822bu: error beacon valid
>   rtw_8822bu: failed to download drv rsvd page
> 
> The failure is intermittent because the poll retries sometimes cover
> the transfer time. It occurs in bursts when something triggers repeated
> beacon updates, such as stations associating and disassociating.
> 
> Fix this by making rtw_usb_write_data() wait for the URB to complete
> when it's called from rtw_usb_write_data_rsvd_page(). The new
> rtw_usb_write_port_sync() waits the same way usb_bulk_msg() does: if
> the URB doesn't complete within 5 seconds, it is killed before the
> function returns, so the completion handler can't run after that.
> usb_bulk_msg() itself is not used because it can't set URB_ZERO_PACKET,
> which rtw_usb_write_port() sets for every bulk out transfer.
> 
> Only the reserved page path is made synchronous; the normal data TX
> path and the H2C path are left untouched, so throughput is unaffected.
> The chips with a 3081 WCPU also download their firmware through
> rtw_usb_write_data_rsvd_page(), so those chunks are now sent
> synchronously as well.
> 
> The reserved page download runs in process context under rtwdev->mutex,
> so sleeping there is safe.
> 
> Closes: https://github.com/lwfinger/rtw88/issues/451
> Signed-off-by: Mohammed Afifi <i.mafifi17@gmail.com>
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> Co-developed-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
> Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>

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




      reply	other threads:[~2026-10-13  3:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13  3:37 [PATCH rtw-next v5] wifi: rtw88: usb: Download the reserved page synchronously Josef Schlehofer
2026-10-13  3:50 ` Ping-Ke Shih [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=adc49955e3e24177b3e935617d80ed0a@realtek.com \
    --to=pkshih@realtek.com \
    --cc=i.mafifi17@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pepe.schlehofer@gmail.com \
    --cc=rtl8821cerfe2@gmail.com \
    /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