[PATCH] USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID

[David Kozub]

There is another JMS567-based USB3 UAS enclosure (152d:0578) that fails
with the following error:

[sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[sda] tag#0 Sense Key : Illegal Request [current]
[sda] tag#0 Add. Sense: Invalid field in cdb

The issue occurs both with UAS (occasionally) and mass storage
(immediately after mounting a FS on a disk in the enclosure).

Enabling US_FL_BROKEN_FUA quirk solves this issue.

This patch adds an UNUSUAL_DEV with US_FL_BROKEN_FUA for the enclosure
for both UAS and mass storage.

Signed-off-by: David Kozub <z...@linux.fjfi.cvut.cz>
---
 drivers/usb/storage/unusual_devs.h | 7 +++
 drivers/usb/storage/unusual_uas.h  | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/drivers/usb/storage/unusual_devs.h 
b/drivers/usb/storage/unusual_devs.h
index 2968046e7c05..f72d045ee9ef 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2100,6 +2100,13 @@ UNUSUAL_DEV(  0x152d, 0x0567, 0x0114, 0x0116,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA ),
 
+/* Reported by David Kozub <z...@linux.fjfi.cvut.cz> */
+UNUSUAL_DEV(0x152d, 0x0578, 0x, 0x,
+   "JMicron",
+   "JMS567",
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+   US_FL_BROKEN_FUA),
+
 /*
  * Reported by Alexandre Oliva <ol...@lsd.ic.unicamp.br>
  * JMicron responds to USN and several other SCSI ioctls with a
diff --git a/drivers/usb/storage/unusual_uas.h 
b/drivers/usb/storage/unusual_uas.h
index d520374a824e..e6127fb21c12 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -129,6 +129,13 @@ UNUSUAL_DEV(0x152d, 0x0567, 0x, 0x,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA | US_FL_NO_REPORT_OPCODES),
 
+/* Reported-by: David Kozub <z...@linux.fjfi.cvut.cz> */
+UNUSUAL_DEV(0x152d, 0x0578, 0x, 0x,
+   "JMicron",
+   "JMS567",
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+   US_FL_BROKEN_FUA),
+
 /* Reported-by: Hans de Goede <hdego...@redhat.com> */
 UNUSUAL_DEV(0x2109, 0x0711, 0x, 0x,
"VIA",
-- 
2.15.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

"Illegal Request" with JMicron JMS567-based USB3 HDD enclosure

[David Kozub]

Hi all,

I'm observing the following error with a JMS567-based USB3 HDD enclosure:

sd 6:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE

sd 6:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current]
sd 6:0:0:0: [sda] tag#0 Add. Sense: Invalid field in cdb

It's reproducible with Linus' master - I tested with 2db767d988.

Looking into drivers/usb/storage I see there is already a bunch of 
UNUSUAL_DEV entries for the JMS567 but my device (Icy Box IB-254U3) has a 
different USB product ID:


Bus 004 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA 
Technology Corp.


When I add an UNUSUAL_DEV entry for this ID too, the issue seems to go 
away. But I'm not sure what is the proper way to add this:


* US_FL_BROKEN_FUA seems to be the important quirk but I see some other 
JMS567 entries also use US_FL_NO_REPORT_OPCODES. Is there a way to test if 
this quirk is needed for my device? The enclosure seems to work OK even 
without this.


* While normally the device is used via UAS (so I added the UNUSUAL_DEV to 
unusual_uas.h), it's possible to use it in mass storage mode too (e.g. by 
building a kernel without CONFIG_USB_UAS), and when I do so, I get the 
same "Illegal Request", so I should add an UNUSUAL_DEV in unusual_devs.h 
too, right?


* What values should I use for bcdDeviceMin and bcdDeviceMax? I only have 
two such enclosures bought at different times and both have bcdDevice = 
1.14 so should I specify bcdDeviceMin = bcdDeviceMax = 0x0114 or should 
I use 0x and 0x as some other UNUSUAL_DEVs do?


Best regards,

David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html