Re: [PATCH RFC] drivers/rufs: add Rust UFS host controller driver

[Andreas Hindborg <a.hindborg@kernel.org>]

"Bean Huo" <huobean@gmail.com> writes:

> On Sat, 2026-09-12 at 13:00 +0200, Andreas Hindborg wrote:
>> "Greg KH" <gregkh@linuxfoundation.org> writes:
>>
>> > On Sat, Sep 12, 2026 at 12:52:55AM +0900, Jaemyung Lee via B4 Relay wrote:
>> > > Comments on the decision to bypass the SCSI midlayer, the blk-mq model
>> > > used
>> > > in its place, and the proposed prerequisite API boundaries would be
>> > > especially welcome.
>> >
>> > Many many years ago, the USB subsystem tried to bypass the SCSI midlayer
>> > for its storage driver, and while it was a "quick solution" at the time,
>> > in the end, it didn't work out and we dropped the driver as it just made
>> > no sense to keep duplicating all of the logic all the time.
>> >
>> > So I wouldn't recommend it, as long as UFS builds on top of the SCSI
>> > commands and the like, you should not attempt to duplicate it in a
>> > separate driver, no matter how much "simpler" it initially seems to be.
>>
>> The scsi related code in this driver is less than 300 lines and is
>> mostly struct packing/unpacking. I guess we could lift the struct
>> definitions from the scsi layer via bindgen. But at 280 lines I am not
>> sure it is worth it, and it hardly counts as duplication.
>
> I agree the SCSI code in this RFC is small today. But I think it is small
> because the hard parts are not ready in your RFC yet, not because UFS does not
> need them.
>
> The SCSI logic is also not only in protocol/scsi.rs. upiu.rs decodes SAM status,
> and queue.rs parses sense data and decides retries.

Yes, you are right. But it is still very minimal bits of logic. I
definitely want to encapsulate all SCSI logic in a single place now, so
it is more clear.

> And some things are already
> missing because the driver does not use sd and the SCSI error handling:
>
> 1, VPD block limits are not read, and a discard of 4 GiB or more fails with
> EOVERFLOW
> 2, the cache mode page is not read, so FLUSH/FUA are likely never sent
> 3, the residual count is ignored, so a short transfer completes as success
> 4, UNIT ATTENTION and BUSY are requeued without a limit
> 5, LUs are found by 0..bNumberLU, not REPORT LUNS, so sparse LUs are missed
> 6, no START STOP UNIT at shutdown
>
> Each of these needs more SCSI code in your RUFS. For comparison, sd.c,
> scsi_error.c, scsi_lib.c and scsi_scan.c are about 15000+ lines today, and
> ufshcd uses all of them. Once RUFS has error handling, power management, RPMB
> and SG_IO, I expect the SCSI part will be large, and it will be a second copy of
> code we already have and maintain.

I cannot counter this argument without proof of existence. But I don't think
we will be anywhere near 15k lines extra to add these features.

> I suggest you samsung first works in JEDEC, together with the other UFS vendors
> and host controller vendors, to remove scsi from the UFS spec as the application
> layer.

I appreciate the input.

> As long as scsi is the UFS application layer, every UFS device must still
> uses scsi, decode scsi in FW, and RUFS must still send SCSI commands and handle
> SCSI status and sense data, as it does today. Moving this SCSI work out of the
> SCSI midlayer and into a new driver does not make the whole ecosystem simpler.

It may not make the ecosystem simpler at first, but I do believe it will
make the driver more simple.

> It only means the same SCSI work is done in two places, and it can even make
> things worse.

It's a very small part though, so it should be fairly easy to manage. I
do acknowledge that our RFC driver has bits sprinkled about, and that
making it feature complete will make these bits grow. I don't think it
will grow as much as you hint at.

> If the spec changes, then a new driver built on native UFS commands would make
> much more sense. That is the first thing to do, not just post an RFC
> patch.

We did send this patch with the intention of starting this exact
conversation, so there is that. I appreciate your input that you would
prefer the conversation to be started in a different channel.

> I
> could send a Rust based UFS driver as well with AI assist, but that does not
> make it sensible to change the base of our current UFS ecosystem.

I am not sure what to read from this. I want to make it very clear that
this patch is not some kind of vibe coded pile of AI slop. I'd love to
discuss responsible and efficient use of LLMs for kernel work, but this
thread is not the place for that conversation.

Best regards,
Andreas Hindborg