@@ -1476,6 +1476,17 @@ UNUSUAL_DEV( 0x0bc2, 0x3332, 0x0000, 0x9999,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_NO_WP_DETECT ),
+/*
+ * Realtek 9210 family set global write-protection flag
+ * for any OPAL locking range making device unusable
+ * Reported-by: Milan Broz <gmazyland@gmail.com>
+ */
+UNUSUAL_DEV( 0x0bda, 0x9210, 0x0000, 0xffff,
+ "Realtek",
+ "",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_IGNORE_OPAL),
+
UNUSUAL_DEV( 0x0d49, 0x7310, 0x0000, 0x9999,
"Maxtor",
"USB to SATA",
@@ -185,3 +185,14 @@ UNUSUAL_DEV(0x4971, 0x8024, 0x0000, 0x9999,
"External HDD",
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_ALWAYS_SYNC),
+
+/*
+ * Realtek 9210 family set global write-protection flag
+ * for any OPAL locking range making device unusable
+ * Reported-by: Milan Broz <gmazyland@gmail.com>
+ */
+UNUSUAL_DEV(0x0bda, 0x9210, 0x0000, 0xffff,
+ "Realtek",
+ "",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_IGNORE_OPAL),
Realtek 9210 family (NVME to USB bridge) adapters always set the write-protected bit for the whole drive if an OPAL locking range is defined (even if the OPAL locking range just covers part of the disk). The only way to recover is PSID reset and physical reconnection of the device. This looks like a wrong implementation of OPAL standard (and I will try to report it to Realtek as it happens for all firmware versions I have), but for now, these adapters are unusable for OPAL. Signed-off-by: Milan Broz <gmazyland@gmail.com> --- drivers/usb/storage/unusual_devs.h | 11 +++++++++++ drivers/usb/storage/unusual_uas.h | 11 +++++++++++ 2 files changed, 22 insertions(+)