UAS peripheral with unrecognized TRIM support

UAS peripheral with unrecognized TRIM support

[Johan Gill]

Hi, I have tested running Linux on the StarTech USB312SAT3CB USB 3.1 -> 
SATA adapter. It's a more stable UAS implementation than my previous 
adapter but the device is not recognized as supporting TRIM out of the 
box (kernel 6.19.9). The technical specifications at 
https://www.startech.com/en-se/hdd/usb312sat3cb indicate that TRIM is 
supported, so I enabled it by setting ATTR{provisioning_mode}="unmap" in 
a udev rule and then fstrim indeed seems to work when I run it. The 
specification claims that it uses ASMedia ASM235CM, but the device uses 
the StarTech vendor id and identifies as 14b0:0207.

It would be nice to have the adapter recognized as more capable out of 
the box. Should I aim at patching drivers/usb/storage/unusual_uas.h?

Re: UAS peripheral with unrecognized TRIM support

[Greg KH]

On Sat, Mar 28, 2026 at 05:23:48PM +0100, Johan Gill wrote:
> Hi, I have tested running Linux on the StarTech USB312SAT3CB USB 3.1 -> SATA
> adapter. It's a more stable UAS implementation than my previous adapter but
> the device is not recognized as supporting TRIM out of the box (kernel
> 6.19.9). The technical specifications at
> https://www.startech.com/en-se/hdd/usb312sat3cb indicate that TRIM is
> supported, so I enabled it by setting ATTR{provisioning_mode}="unmap" in a
> udev rule and then fstrim indeed seems to work when I run it. The
> specification claims that it uses ASMedia ASM235CM, but the device uses the
> StarTech vendor id and identifies as 14b0:0207.
> 
> It would be nice to have the adapter recognized as more capable out of the
> box. Should I aim at patching drivers/usb/storage/unusual_uas.h?

Isn't that a scsi issue, not a USB/UAS issue to be reporting that value
properly?  That sysfs attribute comes from the storage portion of the
kernel, not the USB portion.

thanks,

greg k-h

Re: UAS peripheral with unrecognized TRIM support

[Oliver Neukum]

On 28.03.26 17:23, Johan Gill wrote:

> It would be nice to have the adapter recognized as more capable out of the box. Should I aim at patching drivers/usb/storage/unusual_uas.h?

No,

because

1) we cannot be sure why the VPD is wrong. Worst case is that it works
on some devices, but not others and the vendor is conservative
2) this is a SCSI issue, not a USB issue. Storage and UAS devices
can be real converters to a SCSI bus or device enclosures for
arbitrary disks, whose capabilities depend on the concrete disk used
in them

Hence this issue cannot be solved at the level of UAS. You need
to get a quirk on the SCSI level and discuss this with the SCSI
list.

	HTH
		Oliver