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

[Bean Huo]

On Sat, 2026-09-12 at 13:20 +0200, Andreas Hindborg wrote:
> > 
> > You still use scsi everywhere in your implementation protocol/scsi.rs builds
> > READ_10/16, WRITE_10/16, SYNCHRONIZE_CACHE and UNMAP CDB, so "decouple UFS
> > from
> > SCSI" really means "copy a small part of sd and the SCSI error handling into
> > a
> > UFS driver." while JEDEC defines the UFS application layer as SCSI, the SCSI
> > work doesn't go away, you just move somewhere else, and it has to be written
> > again.
> 
> See my response to Greg. The SCSI specific code in this driver is very
> minimal.
> 

Let me reply this in your another email,

> > 
> > The "friction" claim is weak. SCSI has already been changed to fit UFS. Two
> > examples: UFS now uses SCSI simple copy, group number in scsi write command.
> > 
> > I doubt how far this can go. do we really need to pay effort for a new RUST
> > UFS
> > driver, I am not very confident, unless SCSI is removed from the UFS spec
> > and
> > JEDEC defines native UFS commands, or we talk to the device directly with
> > UPIU.
> > please name the JEDEC feature that the SCSI midlayer really blocked, or that
> > was
> > historial issue which has been fixed.
> 
> I am sure the UFS experts will be able to answer this better than me.
> 


this is the main reason in your cover letter for leaving SCSI. I think the
authors should name the feature, because without a real example it is hard to
see why the SCSI work should be done again in a new driver.


> > I would also like to see the heavy and hard parts, because they are the
> > parts
> > that decide if this design worrks:
> > 
> > 1, error handling: abort, LU reset, retries with limits, sense decoding,
> > this is
> > the very hard part of UFS driver.
> 
> I agree. However, we decided to get the discussion going with a smaller
> feature set. We can build an efficient feature complete driver, but we
> would really like to talk to the community about it first.
> 

I understand you want to start small. But error handling is not only a missing
feature. It decides the design. Things like getting a free tag for a device
command while I/O is stuck, abort, LU reset, and what happens when recovery
fails, are the parts the SCSI midlayer gives us today. In this RFC, when
recovery fails the queue stays quiesced and I/O hangs forever. So I would like
to see at least a design for this before we discuss the rest.

> > 2, user-space tools interface: SG_IO and bsg (sg3_utils, ufs-utils, FFU with
> > WRITE BUFFER), and the UFS sysfs tree..
> 
> On the account of this not being a scsi driver, some changes would have
> to be made. But we should be able support
> /sys/bus/platform/drivers/ufshcd/* just fine.
> 

the host attributes in sysfs are only a small part. The per-LU attributes are
documented under /sys/class/scsi_device//device/unit_descriptor/, and ufs-bsg is
named after the SCSI host number. More important, FFU with WRITE BUFFER, RPMB
with SECURITY PROTOCOL, and vendor tools all use SG_IO through  /dev/sg. These
are user-space interfaces people use in products today, so "some changes" here
means breaking them. How do you plan to keep them working? Also, the sysfs path
contains "ufshcd", while RUFS registers as "rufs".


> > Did any AI tool help write this code? If so, please add the Assisted-by:
> > tag.
> 
> We use AI for code review and spell checking, so I guess the tag is warranted.
> 

Thanks for agreeing to add the Assisted-by tag.

Kind regards,
Beamn