* [PATCH] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa)
@ 2026-10-13 22:19 Olivier Kaloudoff
2026-10-13 22:23 ` sashiko-bot
` (3 more replies)
0 siblings, 4 replies; 9+ messages in thread
From: Olivier Kaloudoff @ 2026-10-13 22:19 UTC (permalink / raw)
To: linux-usb; +Cc: stern, gregkh, usb-storage, Olivier Kaloudoff, stable
The ASMedia chip detection in uas_use_uas_driver() assumes that every
device with idVendor/idProduct 174c:5106 or 174c:55aa reporting a
config.MaxPower of 0 is an ASM1153 with working UAS.
ASMT135x bridges (iProduct "ASMT135x") share the same 174c:55aa id and
also report MaxPower == 0, so they take the "ASM1153, do nothing"
path — but their UAS implementation is broken:
- The first READ(16) issued by sd probing times out after 30 s;
enumeration only completes after a uas_eh_abort_handler plus a full
uas_eh_host_reset_handler cycle:
scsi 3:0:0:0: Direct-Access ASMT ASMT135x 0 PQ: 0 ANSI: 6
sd 3:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
sd 3:0:0:0: [sdb] tag#26 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
scsi host3: uas_eh_host_reset_handler start
usb 6-2: reset SuperSpeed USB device number 2 using xhci_hcd
scsi host3: uas_eh_host_reset_handler success
- Under concurrent load the bridge stalls: all inflight commands (20+
UAS tags in the captured incident, mixed READ(16)/WRITE(16)) hit the
30 s UAS timeout in the same event, forcing repeated abort/reset
cycles and eventually a USB disconnect. Writes dropped mid-flight
during these resets returned zeros to the filesystem (observed as
XFS metadata corruption on the mounted volume).
- Sequential-write throughput is ~45 MiB/s under UAS versus ~136 MiB/s
after disabling UAS (usb-storage BOT mode), which is fully stable:
several tens of GiB written without a single error.
- Bulk reads of healthy LBA ranges do work under UAS (~190 MiB/s, no
errors); the failure pattern is command-timeout at enumeration and
under queue depth / write load, not a broken transfer path.
Since 174c:55aa is shared across several ASMedia bridges and enclosure
rebrandings, distinguish the ASMT135x by its product string — the same
approach used for the HIKSEMI MD202 check a few lines below. The
product strings of working bridges using the same id ("ASM1053E",
"ASM1153", "ASM1153E", "ASM1351", vendor rebrands such as "YZWY_TECH")
do not contain "ASMT135", so the match is safe.
Verified on an ORICO enclosure (iManufacturer "ASMT", iProduct
"ASMT135x", bcdDevice 1.00) attached through an Alpine Ridge TB3 dock:
with the equivalent usb-storage quirks parameter (174c:55aa:u) the
device is completely stable.
Cc: stable@vger.kernel.org
Signed-off-by: Olivier Kaloudoff <olivier.kaloudoff@gmail.com>
---
lsusb -v for the affected ASMT135x bridge (Bus 006 Dev 002) and the
second, unaffected 174c:55aa bridge on the same host (Bus 010,
iProduct "YZWY_TECH", keeps working UAS):
Couldn't open device, some information will be missing
Bus 006 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Negotiated speed: SuperSpeed (5Gbps)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.20
bDeviceClass 0 [unknown]
bDeviceSubClass 0 [unknown]
bDeviceProtocol 0
bMaxPacketSize0 9
idVendor 0x174c ASMedia Technology Inc.
idProduct 0x55aa ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
bcdDevice 1.00
iManufacturer 2 ASMT
iProduct 3 ASMT135x
iSerial 1 123456789053
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0079
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 1
bNumEndpoints 4
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 98 USB Attached SCSI
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 32
Data-in pipe (0x03)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 32
Data-out pipe (0x04)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 32
Status pipe (0x02)
Endpoint Descriptor:
bLength 7
bDescriptorTCouldn't open device, some information will be missing
ype 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Command pipe (0x01)
Bus 010 Device 003: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Negotiated speed: SuperSpeed (5Gbps)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 0 [unknown]
bDeviceSubClass 0 [unknown]
bDeviceProtocol 0
bMaxPacketSize0 9
idVendor 0x174c ASMedia Technology Inc.
idProduct 0x55aa ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
bcdDevice 1.00
iManufacturer 2 Min Yi USB Device
iProduct 3 YZWY_TECH
iSerial 1 123456789020
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0079
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 1
bNumEndpoints 4
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 98 USB Attached SCSI
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 32
Data-in pipe (0x03)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 32
Data-out pipe (0x04)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
MaxStreams 32
Status pipe (0x02)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 0
Command pipe (0x01)
drivers/usb/storage/uas-detect.h | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/storage/uas-detect.h b/drivers/usb/storage/uas-detect.h
index 4d3b49e5b87a..f0d9748b0194 100644
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -78,6 +78,8 @@ static int uas_use_uas_driver(struct usb_interface *intf,
* ASM1051 - with broken (*) uas support
* ASM1053 - with working uas support, but problems with large xfers
* ASM1153 - with working uas support
+ * ASMT135x - broken uas support, shares the ASM1153 MaxPower == 0
+ * signature, identify it by its product string
*
* Devices with these chips re-use a number of device-ids over the
* entire line, so the device-id is useless to determine if we're
@@ -99,7 +101,10 @@ static int uas_use_uas_driver(struct usb_interface *intf,
(le16_to_cpu(udev->descriptor.idProduct) == 0x5106 ||
le16_to_cpu(udev->descriptor.idProduct) == 0x55aa)) {
if (udev->actconfig->desc.bMaxPower == 0) {
- /* ASM1153, do nothing */
+ if (udev->product && strstr(udev->product, "ASMT135"))
+ /* ASMT135x, broken uas */
+ flags |= US_FL_IGNORE_UAS;
+ /* else ASM1153, do nothing */
} else if (udev->speed < USB_SPEED_SUPER) {
/* No streams info, assume ASM1051 */
flags |= US_FL_IGNORE_UAS;
--
2.47.3
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa)
2026-10-13 22:19 [PATCH] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa) Olivier Kaloudoff
@ 2026-10-13 22:23 ` sashiko-bot
2026-10-14 5:00 ` Greg KH
` (2 subsequent siblings)
3 siblings, 0 replies; 9+ messages in thread
From: sashiko-bot @ 2026-10-13 22:23 UTC (permalink / raw)
To: Olivier Kaloudoff, linux-usb
> The ASMedia chip detection in uas_use_uas_driver() assumes that every
> device with idVendor/idProduct 174c:5106 or 174c:55aa reporting a
> config.MaxPower of 0 is an ASM1153 with working UAS.
>
> ASMT135x bridges (iProduct "ASMT135x") share the same 174c:55aa id and
> also report MaxPower == 0, so they take the "ASM1153, do nothing"
> path — but their UAS implementation is broken:
>
> - The first READ(16) issued by sd probing times out after 30 s;
> enumeration only completes after a uas_eh_abort_handler plus a full
> uas_eh_host_reset_handler cycle:
>
> scsi 3:0:0:0: Direct-Access ASMT ASMT135x 0 PQ: 0 ANSI: 6
> sd 3:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
> sd 3:0:0:0: [sdb] tag#26 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
> [ ... ]
> with the equivalent usb-storage quirks parameter (174c:55aa:u) the
> device is completely stable.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Olivier Kaloudoff <olivier.kaloudoff@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261013221944.41598-1-olivier.kaloudoff@gmail.com?part=1
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa)
2026-10-13 22:19 [PATCH] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa) Olivier Kaloudoff
2026-10-13 22:23 ` sashiko-bot
@ 2026-10-14 5:00 ` Greg KH
2026-10-14 10:57 ` [PATCH v2] " Olivier Kaloudoff
2026-10-14 16:57 ` [PATCH v3] " Olivier Kaloudoff
3 siblings, 0 replies; 9+ messages in thread
From: Greg KH @ 2026-10-14 5:00 UTC (permalink / raw)
To: Olivier Kaloudoff; +Cc: linux-usb, stern, usb-storage, stable
On Wed, Oct 14, 2026 at 12:19:44AM +0200, Olivier Kaloudoff wrote:
> diff --git a/drivers/usb/storage/uas-detect.h b/drivers/usb/storage/uas-detect.h
> index 4d3b49e5b87a..f0d9748b0194 100644
> --- a/drivers/usb/storage/uas-detect.h
> +++ b/drivers/usb/storage/uas-detect.h
> @@ -78,6 +78,8 @@ static int uas_use_uas_driver(struct usb_interface *intf,
> * ASM1051 - with broken (*) uas support
> * ASM1053 - with working uas support, but problems with large xfers
> * ASM1153 - with working uas support
> + * ASMT135x - broken uas support, shares the ASM1153 MaxPower == 0
> + * signature, identify it by its product string
> *
> * Devices with these chips re-use a number of device-ids over the
> * entire line, so the device-id is useless to determine if we're
Please always check your patches before sending them out :(
thanks,
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v2] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa)
2026-10-13 22:19 [PATCH] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa) Olivier Kaloudoff
2026-10-13 22:23 ` sashiko-bot
2026-10-14 5:00 ` Greg KH
@ 2026-10-14 10:57 ` Olivier Kaloudoff
2026-10-14 11:02 ` sashiko-bot
2026-10-14 11:16 ` Greg KH
2026-10-14 16:57 ` [PATCH v3] " Olivier Kaloudoff
3 siblings, 2 replies; 9+ messages in thread
From: Olivier Kaloudoff @ 2026-10-14 10:57 UTC (permalink / raw)
To: linux-usb; +Cc: stern, gregkh, usb-storage, Olivier Kaloudoff, stable
The ASMedia chip detection in uas_use_uas_driver() assumes that every
device with idVendor/idProduct 174c:5106 or 174c:55aa reporting a
config.MaxPower of 0 is an ASM1153 with working UAS.
ASMT135x bridges (iProduct "ASMT135x") share the same 174c:55aa id and
also report MaxPower == 0, so they take the "ASM1153, do nothing"
path — but their UAS implementation is broken:
- The first READ(16) issued by sd probing times out after 30 s;
enumeration only completes after a uas_eh_abort_handler plus a full
uas_eh_host_reset_handler cycle:
scsi 3:0:0:0: Direct-Access ASMT ASMT135x 0 PQ: 0 ANSI: 6
sd 3:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
sd 3:0:0:0: [sdb] tag#26 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
scsi host3: uas_eh_host_reset_handler start
usb 6-2: reset SuperSpeed USB device number 2 using xhci_hcd
scsi host3: uas_eh_host_reset_handler success
- Under concurrent load the bridge stalls: all inflight commands (20+
UAS tags in the captured incident, mixed READ(16)/WRITE(16)) hit the
30 s UAS timeout in the same event, forcing repeated abort/reset
cycles and eventually a USB disconnect. Writes dropped mid-flight
during these resets returned zeros to the filesystem (observed as
XFS metadata corruption on the mounted volume).
- Sequential-write throughput is ~45 MiB/s under UAS versus ~136 MiB/s
after disabling UAS (usb-storage BOT mode), which is fully stable:
several tens of GiB written without a single error.
- Bulk reads of healthy LBA ranges do work under UAS (~190 MiB/s, no
errors); the failure pattern is command-timeout at enumeration and
under queue depth / write load, not a broken transfer path.
Since 174c:55aa is shared across several ASMedia bridges and enclosure
rebrandings, distinguish the ASMT135x by its product string — the same
approach used for the HIKSEMI MD202 check a few lines below. The
product strings of working bridges using the same id ("ASM1053E",
"ASM1153", "ASM1153E", "ASM1351", vendor rebrands such as "YZWY_TECH")
do not contain "ASMT135", so the match is safe.
Verified on an ORICO enclosure (iManufacturer "ASMT", iProduct
"ASMT135x", bcdDevice 1.00) attached through an Alpine Ridge TB3 dock:
with the equivalent usb-storage quirks parameter (174c:55aa:u) the
device is completely stable.
Cc: stable@vger.kernel.org
Signed-off-by: Olivier Kaloudoff <olivier.kaloudoff@gmail.com>
---
v2: fix the comment block: added lines were missing the leading
tab, breaking the *-alignment with the rest of the block.
Apologies — the v1 diff was mangled by my editor before sending.
drivers/usb/storage/uas-detect.h | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/storage/uas-detect.h b/drivers/usb/storage/uas-detect.h
index 4d3b49e5b87a..d8dc77015992 100644
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -78,6 +78,8 @@ static int uas_use_uas_driver(struct usb_interface *intf,
* ASM1051 - with broken (*) uas support
* ASM1053 - with working uas support, but problems with large xfers
* ASM1153 - with working uas support
+ * ASMT135x - broken uas support, shares the ASM1153 MaxPower == 0
+ * signature, identify it by its product string
*
* Devices with these chips re-use a number of device-ids over the
* entire line, so the device-id is useless to determine if we're
@@ -99,7 +101,10 @@ static int uas_use_uas_driver(struct usb_interface *intf,
(le16_to_cpu(udev->descriptor.idProduct) == 0x5106 ||
le16_to_cpu(udev->descriptor.idProduct) == 0x55aa)) {
if (udev->actconfig->desc.bMaxPower == 0) {
- /* ASM1153, do nothing */
+ if (udev->product && strstr(udev->product, "ASMT135"))
+ /* ASMT135x, broken uas */
+ flags |= US_FL_IGNORE_UAS;
+ /* else ASM1153, do nothing */
} else if (udev->speed < USB_SPEED_SUPER) {
/* No streams info, assume ASM1051 */
flags |= US_FL_IGNORE_UAS;
--
2.47.3
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v2] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa)
2026-10-14 10:57 ` [PATCH v2] " Olivier Kaloudoff
@ 2026-10-14 11:02 ` sashiko-bot
2026-10-14 11:16 ` Greg KH
1 sibling, 0 replies; 9+ messages in thread
From: sashiko-bot @ 2026-10-14 11:02 UTC (permalink / raw)
To: Olivier Kaloudoff, linux-usb
> The ASMedia chip detection in uas_use_uas_driver() assumes that every
> device with idVendor/idProduct 174c:5106 or 174c:55aa reporting a
> config.MaxPower of 0 is an ASM1153 with working UAS.
>
> ASMT135x bridges (iProduct "ASMT135x") share the same 174c:55aa id and
> also report MaxPower == 0, so they take the "ASM1153, do nothing"
> path — but their UAS implementation is broken:
>
> - The first READ(16) issued by sd probing times out after 30 s;
> enumeration only completes after a uas_eh_abort_handler plus a full
> uas_eh_host_reset_handler cycle:
>
> scsi 3:0:0:0: Direct-Access ASMT ASMT135x 0 PQ: 0 ANSI: 6
> sd 3:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
> sd 3:0:0:0: [sdb] tag#26 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
> [ ... ]
> with the equivalent usb-storage quirks parameter (174c:55aa:u) the
> device is completely stable.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Olivier Kaloudoff <olivier.kaloudoff@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261014105700.19433-1-olivier.kaloudoff@gmail.com?part=1
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v2] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa)
2026-10-14 10:57 ` [PATCH v2] " Olivier Kaloudoff
2026-10-14 11:02 ` sashiko-bot
@ 2026-10-14 11:16 ` Greg KH
1 sibling, 0 replies; 9+ messages in thread
From: Greg KH @ 2026-10-14 11:16 UTC (permalink / raw)
To: Olivier Kaloudoff; +Cc: linux-usb, stern, usb-storage, stable
On Wed, Oct 14, 2026 at 12:57:00PM +0200, Olivier Kaloudoff wrote:
> The ASMedia chip detection in uas_use_uas_driver() assumes that every
> device with idVendor/idProduct 174c:5106 or 174c:55aa reporting a
> config.MaxPower of 0 is an ASM1153 with working UAS.
>
> ASMT135x bridges (iProduct "ASMT135x") share the same 174c:55aa id and
> also report MaxPower == 0, so they take the "ASM1153, do nothing"
> path — but their UAS implementation is broken:
>
> - The first READ(16) issued by sd probing times out after 30 s;
> enumeration only completes after a uas_eh_abort_handler plus a full
> uas_eh_host_reset_handler cycle:
>
> scsi 3:0:0:0: Direct-Access ASMT ASMT135x 0 PQ: 0 ANSI: 6
> sd 3:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
> sd 3:0:0:0: [sdb] tag#26 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
> scsi host3: uas_eh_host_reset_handler start
> usb 6-2: reset SuperSpeed USB device number 2 using xhci_hcd
> scsi host3: uas_eh_host_reset_handler success
>
> - Under concurrent load the bridge stalls: all inflight commands (20+
> UAS tags in the captured incident, mixed READ(16)/WRITE(16)) hit the
> 30 s UAS timeout in the same event, forcing repeated abort/reset
> cycles and eventually a USB disconnect. Writes dropped mid-flight
> during these resets returned zeros to the filesystem (observed as
> XFS metadata corruption on the mounted volume).
>
> - Sequential-write throughput is ~45 MiB/s under UAS versus ~136 MiB/s
> after disabling UAS (usb-storage BOT mode), which is fully stable:
> several tens of GiB written without a single error.
>
> - Bulk reads of healthy LBA ranges do work under UAS (~190 MiB/s, no
> errors); the failure pattern is command-timeout at enumeration and
> under queue depth / write load, not a broken transfer path.
>
> Since 174c:55aa is shared across several ASMedia bridges and enclosure
> rebrandings, distinguish the ASMT135x by its product string — the same
> approach used for the HIKSEMI MD202 check a few lines below. The
> product strings of working bridges using the same id ("ASM1053E",
> "ASM1153", "ASM1153E", "ASM1351", vendor rebrands such as "YZWY_TECH")
> do not contain "ASMT135", so the match is safe.
>
> Verified on an ORICO enclosure (iManufacturer "ASMT", iProduct
> "ASMT135x", bcdDevice 1.00) attached through an Alpine Ridge TB3 dock:
> with the equivalent usb-storage quirks parameter (174c:55aa:u) the
> device is completely stable.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Olivier Kaloudoff <olivier.kaloudoff@gmail.com>
> ---
> v2: fix the comment block: added lines were missing the leading
> tab, breaking the *-alignment with the rest of the block.
> Apologies — the v1 diff was mangled by my editor before sending.
>
> drivers/usb/storage/uas-detect.h | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/storage/uas-detect.h b/drivers/usb/storage/uas-detect.h
> index 4d3b49e5b87a..d8dc77015992 100644
> --- a/drivers/usb/storage/uas-detect.h
> +++ b/drivers/usb/storage/uas-detect.h
> @@ -78,6 +78,8 @@ static int uas_use_uas_driver(struct usb_interface *intf,
> * ASM1051 - with broken (*) uas support
> * ASM1053 - with working uas support, but problems with large xfers
> * ASM1153 - with working uas support
> + * ASMT135x - broken uas support, shares the ASM1153 MaxPower == 0
> + * signature, identify it by its product string
> *
> * Devices with these chips re-use a number of device-ids over the
> * entire line, so the device-id is useless to determine if we're
> @@ -99,7 +101,10 @@ static int uas_use_uas_driver(struct usb_interface *intf,
> (le16_to_cpu(udev->descriptor.idProduct) == 0x5106 ||
> le16_to_cpu(udev->descriptor.idProduct) == 0x55aa)) {
> if (udev->actconfig->desc.bMaxPower == 0) {
> - /* ASM1153, do nothing */
> + if (udev->product && strstr(udev->product, "ASMT135"))
> + /* ASMT135x, broken uas */
> + flags |= US_FL_IGNORE_UAS;
You have a 2 line statement after the if () here without any {}.
Yes, it will work (or it should), but it's not good form and will
confuse us over time. Please fix this up, odd that checkpatch.pl didn't
catch it.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v3] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa)
2026-10-13 22:19 [PATCH] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa) Olivier Kaloudoff
` (2 preceding siblings ...)
2026-10-14 10:57 ` [PATCH v2] " Olivier Kaloudoff
@ 2026-10-14 16:57 ` Olivier Kaloudoff
2026-10-14 17:02 ` sashiko-bot
2026-10-14 19:04 ` [usb-storage] " Alan Stern
3 siblings, 2 replies; 9+ messages in thread
From: Olivier Kaloudoff @ 2026-10-14 16:57 UTC (permalink / raw)
To: linux-usb; +Cc: stern, gregkh, usb-storage, Olivier Kaloudoff
The ASMedia chip detection in uas_use_uas_driver() assumes that every
device with idVendor/idProduct 174c:5106 or 174c:55aa reporting a
config.MaxPower of 0 is an ASM1153 with working UAS.
ASMT135x bridges (iProduct "ASMT135x") share the same 174c:55aa id and
also report MaxPower == 0, so they take the "ASM1153, do nothing"
path — but their UAS implementation is broken:
- The first READ(16) issued by sd probing times out after 30 s;
enumeration only completes after a uas_eh_abort_handler plus a full
uas_eh_host_reset_handler cycle:
scsi 3:0:0:0: Direct-Access ASMT ASMT135x 0 PQ: 0 ANSI: 6
sd 3:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
sd 3:0:0:0: [sdb] tag#26 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
scsi host3: uas_eh_host_reset_handler start
usb 6-2: reset SuperSpeed USB device number 2 using xhci_hcd
scsi host3: uas_eh_host_reset_handler success
- Under concurrent load the bridge stalls: all inflight commands (20+
UAS tags in the captured incident, mixed READ(16)/WRITE(16)) hit the
30 s UAS timeout in the same event, forcing repeated abort/reset
cycles and eventually a USB disconnect. Writes dropped mid-flight
during these resets returned zeros to the filesystem (observed as
XFS metadata corruption on the mounted volume).
- Sequential-write throughput is ~45 MiB/s under UAS versus ~136 MiB/s
after disabling UAS (usb-storage BOT mode), which is fully stable:
several tens of GiB written without a single error.
- Bulk reads of healthy LBA ranges do work under UAS (~190 MiB/s, no
errors); the failure pattern is command-timeout at enumeration and
under queue depth / write load, not a broken transfer path.
Since 174c:55aa is shared across several ASMedia bridges and enclosure
rebrandings, distinguish the ASMT135x by its product string — the same
approach used for the HIKSEMI MD202 check a few lines below. The
product strings of working bridges using the same id ("ASM1053E",
"ASM1153", "ASM1153E", "ASM1351", vendor rebrands such as "YZWY_TECH")
do not contain "ASMT135", so the match is safe.
Verified on an ORICO enclosure (iManufacturer "ASMT", iProduct
"ASMT135x", bcdDevice 1.00) attached through an Alpine Ridge TB3 dock:
with the equivalent usb-storage quirks parameter (174c:55aa:u) the
device is completely stable.
Signed-off-by: Olivier Kaloudoff <olivier.kaloudoff@gmail.com>
---
v3: add braces around the if-body (per Greg KH).
v2: fix the comment block: added lines were missing the leading
tab, breaking the *-alignment with the rest of the block.
drivers/usb/storage/uas-detect.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/storage/uas-detect.h b/drivers/usb/storage/uas-detect.h
index 4d3b49e5b..523a17cf0 100644
--- a/drivers/usb/storage/uas-detect.h
+++ b/drivers/usb/storage/uas-detect.h
@@ -78,6 +78,8 @@ static int uas_use_uas_driver(struct usb_interface *intf,
* ASM1051 - with broken (*) uas support
* ASM1053 - with working uas support, but problems with large xfers
* ASM1153 - with working uas support
+ * ASMT135x - broken uas support, shares the ASM1153 MaxPower == 0
+ * signature, identify it by its product string
*
* Devices with these chips re-use a number of device-ids over the
* entire line, so the device-id is useless to determine if we're
@@ -99,7 +101,11 @@ static int uas_use_uas_driver(struct usb_interface *intf,
(le16_to_cpu(udev->descriptor.idProduct) == 0x5106 ||
le16_to_cpu(udev->descriptor.idProduct) == 0x55aa)) {
if (udev->actconfig->desc.bMaxPower == 0) {
- /* ASM1153, do nothing */
+ if (udev->product && strstr(udev->product, "ASMT135")) {
+ /* ASMT135x, broken uas */
+ flags |= US_FL_IGNORE_UAS;
+ }
+ /* else ASM1153, do nothing */
} else if (udev->speed < USB_SPEED_SUPER) {
/* No streams info, assume ASM1051 */
flags |= US_FL_IGNORE_UAS;
--
2.47.3
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v3] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa)
2026-10-14 16:57 ` [PATCH v3] " Olivier Kaloudoff
@ 2026-10-14 17:02 ` sashiko-bot
2026-10-14 19:04 ` [usb-storage] " Alan Stern
1 sibling, 0 replies; 9+ messages in thread
From: sashiko-bot @ 2026-10-14 17:02 UTC (permalink / raw)
To: Olivier Kaloudoff, linux-usb
> The ASMedia chip detection in uas_use_uas_driver() assumes that every
> device with idVendor/idProduct 174c:5106 or 174c:55aa reporting a
> config.MaxPower of 0 is an ASM1153 with working UAS.
>
> ASMT135x bridges (iProduct "ASMT135x") share the same 174c:55aa id and
> also report MaxPower == 0, so they take the "ASM1153, do nothing"
> path — but their UAS implementation is broken:
>
> - The first READ(16) issued by sd probing times out after 30 s;
> enumeration only completes after a uas_eh_abort_handler plus a full
> uas_eh_host_reset_handler cycle:
>
> scsi 3:0:0:0: Direct-Access ASMT ASMT135x 0 PQ: 0 ANSI: 6
> sd 3:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
> sd 3:0:0:0: [sdb] tag#26 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
> [ ... ]
> "ASMT135x", bcdDevice 1.00) attached through an Alpine Ridge TB3 dock:
> with the equivalent usb-storage quirks parameter (174c:55aa:u) the
> device is completely stable.
>
> Signed-off-by: Olivier Kaloudoff <olivier.kaloudoff@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261014165741.35758-1-olivier.kaloudoff@gmail.com?part=1
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [usb-storage] [PATCH v3] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa)
2026-10-14 16:57 ` [PATCH v3] " Olivier Kaloudoff
2026-10-14 17:02 ` sashiko-bot
@ 2026-10-14 19:04 ` Alan Stern
1 sibling, 0 replies; 9+ messages in thread
From: Alan Stern @ 2026-10-14 19:04 UTC (permalink / raw)
To: Olivier Kaloudoff; +Cc: linux-usb, gregkh, usb-storage
On Wed, Oct 14, 2026 at 06:57:41PM +0200, Olivier Kaloudoff wrote:
> The ASMedia chip detection in uas_use_uas_driver() assumes that every
> device with idVendor/idProduct 174c:5106 or 174c:55aa reporting a
> config.MaxPower of 0 is an ASM1153 with working UAS.
>
> ASMT135x bridges (iProduct "ASMT135x") share the same 174c:55aa id and
> also report MaxPower == 0, so they take the "ASM1153, do nothing"
> path — but their UAS implementation is broken:
>
> - The first READ(16) issued by sd probing times out after 30 s;
> enumeration only completes after a uas_eh_abort_handler plus a full
> uas_eh_host_reset_handler cycle:
>
> scsi 3:0:0:0: Direct-Access ASMT ASMT135x 0 PQ: 0 ANSI: 6
> sd 3:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
> sd 3:0:0:0: [sdb] tag#26 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
> scsi host3: uas_eh_host_reset_handler start
> usb 6-2: reset SuperSpeed USB device number 2 using xhci_hcd
> scsi host3: uas_eh_host_reset_handler success
>
> - Under concurrent load the bridge stalls: all inflight commands (20+
> UAS tags in the captured incident, mixed READ(16)/WRITE(16)) hit the
> 30 s UAS timeout in the same event, forcing repeated abort/reset
> cycles and eventually a USB disconnect. Writes dropped mid-flight
> during these resets returned zeros to the filesystem (observed as
> XFS metadata corruption on the mounted volume).
>
> - Sequential-write throughput is ~45 MiB/s under UAS versus ~136 MiB/s
> after disabling UAS (usb-storage BOT mode), which is fully stable:
> several tens of GiB written without a single error.
>
> - Bulk reads of healthy LBA ranges do work under UAS (~190 MiB/s, no
> errors); the failure pattern is command-timeout at enumeration and
> under queue depth / write load, not a broken transfer path.
>
> Since 174c:55aa is shared across several ASMedia bridges and enclosure
> rebrandings, distinguish the ASMT135x by its product string — the same
> approach used for the HIKSEMI MD202 check a few lines below. The
> product strings of working bridges using the same id ("ASM1053E",
> "ASM1153", "ASM1153E", "ASM1351", vendor rebrands such as "YZWY_TECH")
> do not contain "ASMT135", so the match is safe.
>
> Verified on an ORICO enclosure (iManufacturer "ASMT", iProduct
> "ASMT135x", bcdDevice 1.00) attached through an Alpine Ridge TB3 dock:
> with the equivalent usb-storage quirks parameter (174c:55aa:u) the
> device is completely stable.
>
> Signed-off-by: Olivier Kaloudoff <olivier.kaloudoff@gmail.com>
> ---
> v3: add braces around the if-body (per Greg KH).
> v2: fix the comment block: added lines were missing the leading
> tab, breaking the *-alignment with the rest of the block.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
> drivers/usb/storage/uas-detect.h | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/storage/uas-detect.h b/drivers/usb/storage/uas-detect.h
> index 4d3b49e5b..523a17cf0 100644
> --- a/drivers/usb/storage/uas-detect.h
> +++ b/drivers/usb/storage/uas-detect.h
> @@ -78,6 +78,8 @@ static int uas_use_uas_driver(struct usb_interface *intf,
> * ASM1051 - with broken (*) uas support
> * ASM1053 - with working uas support, but problems with large xfers
> * ASM1153 - with working uas support
> + * ASMT135x - broken uas support, shares the ASM1153 MaxPower == 0
> + * signature, identify it by its product string
> *
> * Devices with these chips re-use a number of device-ids over the
> * entire line, so the device-id is useless to determine if we're
> @@ -99,7 +101,11 @@ static int uas_use_uas_driver(struct usb_interface *intf,
> (le16_to_cpu(udev->descriptor.idProduct) == 0x5106 ||
> le16_to_cpu(udev->descriptor.idProduct) == 0x55aa)) {
> if (udev->actconfig->desc.bMaxPower == 0) {
> - /* ASM1153, do nothing */
> + if (udev->product && strstr(udev->product, "ASMT135")) {
> + /* ASMT135x, broken uas */
> + flags |= US_FL_IGNORE_UAS;
> + }
> + /* else ASM1153, do nothing */
> } else if (udev->speed < USB_SPEED_SUPER) {
> /* No streams info, assume ASM1051 */
> flags |= US_FL_IGNORE_UAS;
> --
> 2.47.3
>
> --
> You received this message because you are subscribed to the Google Groups "USB Mass Storage on Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to usb-storage+unsubscribe@lists.one-eyed-alien.net.
> To view this discussion visit https://groups.google.com/a/lists.one-eyed-alien.net/d/msgid/usb-storage/20261014165741.35758-1-olivier.kaloudoff%40gmail.com.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2026-10-14 19:04 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-13 22:19 [PATCH] usb: uas: ignore UAS for ASMT135x bridges (174c:55aa) Olivier Kaloudoff
2026-10-13 22:23 ` sashiko-bot
2026-10-14 5:00 ` Greg KH
2026-10-14 10:57 ` [PATCH v2] " Olivier Kaloudoff
2026-10-14 11:02 ` sashiko-bot
2026-10-14 11:16 ` Greg KH
2026-10-14 16:57 ` [PATCH v3] " Olivier Kaloudoff
2026-10-14 17:02 ` sashiko-bot
2026-10-14 19:04 ` [usb-storage] " Alan Stern
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox