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

[Jaemyung Lee]

On Fri, 2026-09-11 at 23:44 +0200, Bean Huo 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.

I agree. By "decouple" I meant independence from the Linux SCSI mid-layer,
not removal of the SCSI command set from UFS.

The current RFC has CDB construction and only a small part of completion
disposition. It does not yet implement enough sense, retry, recovery, and
disk behavior to show that the complete UFS-specific version is smaller or
simpler. The cover letter stated that conclusion too early.

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

Also fair. I cannot currently name a public JEDEC feature that was
shown to be impossible to implement because of the SCSI mid-layer.

One of my main motivations was the amount of cross-layer reasoning needed
for product EH and PM problems. In product work, I often had to follow UFS
state, generic SCSI recovery state, block queue state, and device-PM state
together. That experience is a reason to investigate another design, but
private product experience is not proof that the upstream architecture is
wrong.

> 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.
>
> 2, user-space tools interface: SG_IO and bsg (sg3_utils, ufs-utils, FFU
> with WRITE BUFFER), and the UFS sysfs tree..

I agree. These are architecture requirements, not small follow-up features.
Before claiming that standalone is useful, the design needs to cover
timeout, abort, LU and host recovery, bounded retries, sense and Unit
Attention, late completion, DMA safety, PM-aware recovery, and request
disposition.

I think the next step should be to document these responsibilities and
compare the standalone design with improving `ufshcd` before completing a
second implementation. If RUFS only reproduces the same behavior and
complexity, the standalone design would need to be reconsidered.

> Did any AI tool help write this code? If so, please add the Assisted-by:
> tag.

Yes. An LLM helped during reviewing, testing and preparation of the
submission. I will add the tag required by the current kernel documentation
in the next revision:

Assisted-by: LLM

Regards,
Jaemyung