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

[Andreas Hindborg]

Bean Huo <beanhuo@xxxxxxxx> writes:

> On Sat, 2026-09-12 at 13:20 +0200, Andreas Hindborg wrote:

[cut]

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

I understand. I'd love to help flesh out the current draft if people are
interested in seeing the result upstream. Maybe as an experimental
driver for a while.

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

Right. I don't think we should build a ufshci driver outside the scsi
midlayer and still provide (linux) scsi compatible interfaces for it. I
understand that userland tools need to be updated, and that carries
cost. I don't imagine enabling a standalone ufshci driver being an over
night switch. If we go down this road, I would assume the legacy driver
and a new driver would coexist for some time.

When that is said, I do think we can provide efficient user space
interfaces that would require minimal code changes for user space
tooling.

For instance, `ufs-bsg` is not really scsi related, it is just a
pass-through interface to the ufs host controller. How you find it would
be the primary change.

Best regards,
Andreas Hindborg