All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ping-Ke Shih <pkshih@realtek.com>
To: "‍김우석[학생](전자정보대학 전자공학과)" <5mghybrid@khu.ac.kr>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc: Jes Sorensen <Jes.Sorensen@gmail.com>,
	Kalle Valo <kvalo@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH rtw-next] wifi: rtl8xxxu: isolate the USB register buffer from CPU state
Date: Tue, 13 Oct 2026 00:44:03 +0000	[thread overview]
Message-ID: <04d26f79d5984920a9584d3f31ec3b58@realtek.com> (raw)
In-Reply-To: <CAH1Bc_yOhZ9oqreJOLKb5RDFEW=0Zid=h4xu9oTR51RDwj_bww@mail.gmail.com>

‍김우석[학생](전자정보대학 전자공학과) <5mghybrid@khu.ac.kr> wrote:
> Hi Ping-Ke,
> 
> > Cool. How did you dig that?
> 
> I was repeatedly power-cycling the AP to test recovery of a persistent
> queue in my project. After fixing a separate NetworkManager issue,
> some reconnect failures remained, so I started looking at the driver.
> 
> I was testing with four Raspberry Pis, and different units would hit
> the same failure across runs. On a failing unit, RF_MODE was corrupted,
> and restoring its initialized value brought reception back.
> 
> I narrowed it down to register corruption during scanning, then traced
> the register access path. That led me to usb_buf sharing a cache line
> with the mutex's waiter state, which can change while a USB transfer
> is in progress.

Does it mean that data in a cache line can't be modified while a USB
transfer? Even the data isn't a part of transferring data.
How can it affect the transfer? 

(I'm not a cache-line expert. Just try to understand the cause).

Ping-Ke


  reply	other threads:[~2026-10-13  0:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09 22:39 [PATCH rtw-next] wifi: rtl8xxxu: isolate the USB register buffer Kim Wooseok via B4 Relay
2026-10-09 22:39 ` Kim Wooseok
2026-10-09 22:39 ` [PATCH rtw-next] wifi: rtl8xxxu: isolate the USB register buffer from CPU state Kim Wooseok via B4 Relay
2026-10-09 22:39   ` Kim Wooseok
2026-10-12  5:44   ` Ping-Ke Shih
2026-10-13  0:15     ` ‍김우석[학생](전자정보대학 전자공학과)
2026-10-13  0:44       ` Ping-Ke Shih [this message]
2026-10-13  0:58         ` Kim Wooseok
2026-10-13  1:09           ` Ping-Ke Shih

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=04d26f79d5984920a9584d3f31ec3b58@realtek.com \
    --to=pkshih@realtek.com \
    --cc=5mghybrid@khu.ac.kr \
    --cc=Jes.Sorensen@gmail.com \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.