From: Dan Carpenter <dan.carpenter@linaro.org>
To: 2023060904@ycu.edu.cn
Cc: gregkh@linuxfoundation.org, guagua210311@qq.com,
linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev
Subject: Re: [PATCH] [rtl8723bs] Remove unnecessary atomic operations for continual_io_error
Date: Tue, 20 Jan 2026 17:18:22 +0300 [thread overview]
Message-ID: <aW-OrprZjcRx8rb_@stanley.mountain> (raw)
In-Reply-To: <641DA44821579DC7+20260120133939.7347-1-2023060904@ycu.edu.cn>
On Tue, Jan 20, 2026 at 09:39:37PM +0800, 2023060904@ycu.edu.cn wrote:
> Hi Dan,
>
> Thank you for the detailed feedback! I'll address each point below:
>
>
> > So you're saying that sd_read32() can only be called by one thread at a
> > time. What sort of locking enforces this? I don't see any at first
> > glance, but I also don't want to invest a lot of time into looking for
> > it. Please explain it clearly in the commit message so reviewers can
> > easily check.
>
> The single-thread guarantee for SDIO IO functions (sd_read32/sd_write8) comes from two key aspects:
> 1. **Linux kernel driver isolation mechanism**: In the Linux kernel, each SDIO device (e.g., the rtl8723bs wireless card) corresponds to an independent driver instance, and the kernel's device model inherently isolates IO requests for different devices. For a single SDIO device, the kernel serializes all IO requests to it — meaning only one IO operation can be processed for the rtl8723bs card at any time, no concurrent requests exist.
The AI is saying obvious stuff here. Reviewers are supposed to be
familiar with kernel basics. It's a waste of time to show reviewers
this paragraph.
> 2. **Driver code logic**: Within the rtl8723bs driver, the sd_read32()/sd_write8() functions are only invoked by the driver's dedicated "IO processing thread". The entire IO execution flow is linear: the driver receives an IO request → processes it via sd_read32()/sd_write8() → completes the request before handling the next one. There is no multi-threaded branching that could call these functions concurrently, so race conditions are impossible.
>
The AI is spouting nonsense. Which function is the "driver's dedicated
IO processing thread"?
regards,
dan carpenter
prev parent reply other threads:[~2026-01-20 14:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-19 8:06 [PATCH] [rtl8723bs] Remove unnecessary atomic operations for continual_io_error 2023060904
2026-01-19 8:20 ` Greg KH
2026-01-20 14:11 ` [PATCH v2 1/2] rtl8723bs: Refactor continual_io_error check 2023060904
2026-01-20 14:34 ` Greg KH
2026-01-21 13:22 ` Dan Carpenter
2026-01-21 13:27 ` Greg KH
[not found] ` <20260120141129.8262-1-2023060904@ycu.edu.cn>
2026-01-20 14:11 ` [PATCH v2 2/2] rtl8723bs: Replace atomic ops with normal vars 2023060904
2026-01-19 8:25 ` [PATCH] [rtl8723bs] Remove unnecessary atomic operations for continual_io_error Dan Carpenter
2026-01-20 13:39 ` 2023060904
2026-01-20 14:05 ` Greg KH
2026-01-20 14:18 ` Dan Carpenter [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=aW-OrprZjcRx8rb_@stanley.mountain \
--to=dan.carpenter@linaro.org \
--cc=2023060904@ycu.edu.cn \
--cc=gregkh@linuxfoundation.org \
--cc=guagua210311@qq.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
/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