Re: [PATCH RFC] drivers/rufs: add Rust UFS host controller driver
From: Jaemyung Lee
Date: Wed Sep 16 2026 - 14:05:53 EST
On Fri, 2026-09-11 at 22:27 +0200, Greg KH wrote:
> 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.
Thank you for pointing us to the `ub` history. I had not considered that
case when working on RUFS.
After reviewing the current SCSI and UFS paths in more detail, I agree that
the initial normal-I/O implementation is not evidence that a standalone
driver remains simpler. The difficult parts are exactly the parts that are
still missing: sense and retry policy, abort and reset escalation, late
completion, power management, device discovery, and existing userspace
interfaces.
I think the next step is to identify concrete problems in the current UFS
integration and compare a standalone design with focused improvements to
`ufshcd`. If the complete design only reproduces SCSI functionality and its
corner cases, a second path would not be justified.
> 30 files and 10000 lines doesn't seem that simple :)
That is fair. Calling the design simple at this stage was not right. The
driver is already substantial while several hard areas are not present.
I will treat the earlier failed approach as a design constraint, not as
history that can be dismissed because UFS is a different device class.
Regards,
Jaemyung