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

[Bean Huo]

On Sat, 2026-09-12 at 13:00 +0200, Andreas Hindborg wrote:
> "Greg KH" <gregkh@xxxxxxxxxxxxxxxxxxx> 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. 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 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. 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 only means the same SCSI work is done in two places, and it can even make
things worse.

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. 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.


Kind regards,
Bean