On Tuesday, October 19, 2021 at 2:01 PM "Greg KH" <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Oct 19, 2021 at 02:53:29PM +0200, mark_k@xxxxxxxxx wrote: > > On Tuesday, October 19, 2021 at 12:18 PM "Greg KH" <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Tue, Oct 19, 2021 at 12:15:09PM +0200, mark_k@xxxxxxxxx wrote: > > > > I have a Core Micro Systems USB2 Link USB-SCSI converter (07B4:0380). > > > > > > > > Adding an entry to unusual_devs.h should get it to work, just needing > > > > USB_PR_BULK. That should at least allow the connected device with SCSI ID 0 > > > > to be accessed. > > > > > > Why do you need any quirk at all for this? > > > > My mistake, sorry. Its interface descriptor has > > bInterfaceClass 0xFF > > bInterfaceSubClass 0x06 > > bInterfaceProtocol 0x50 > > so an entry with USB_SC_DEVICE, USB_PR_DEVICE would work. > > Again, why is a quirk needed at all? bInterfaceClass = 0xFF (not 0x08 which is the mass storage class number) so usb-storage does not bind to it automatically. > > > That should all be up to the scsi layer in the kernel. If this device > > > is not following the standard, how is it supposed to work at all? > > > > > > Does it require custom drivers for other operating systems? > > > > My guess is that (with quirk entry) it will work when there is a SCSI > > device with ID 0. If all other devices in the chain have contiguous IDs > > they could be accessible too. > > > > I can tell Windows to use its built-in mass storage driver and that works > > to access the device with ID 0 only. I haven't yet checked with more than > > one SCSI device in the chain. > > Does this work properly with Linux in this way with no quirk as well? > > And how do you know that the device will work with additional scsi > devices? I rebuilt the usb-storage module after adding an entry for the USB2 Link to unusual_devs.h. With one SCSI device set to ID 0, the kernel detected the drive and I could access it: [ 2219.761126] usb-storage 2-1:1.0: USB Mass Storage device detected [ 2219.762033] scsi host5: usb-storage 2-1:1.0 [ 2219.762163] usbcore: registered new interface driver usb-storage [ 2220.769695] scsi 5:0:0:0: Optical Device HP C1113M 1.19 PQ: 0 ANSI: 2 [ 2221.156254] usb 2-1: reset high-speed USB device number 5 using ehci-pci [ 2221.712223] usb 2-1: reset high-speed USB device number 5 using ehci-pci [ 2222.268262] usb 2-1: reset high-speed USB device number 5 using ehci-pci [ 2222.824239] usb 2-1: reset high-speed USB device number 5 using ehci-pci [ 2222.981475] sd 5:0:0:0: Attached scsi generic sg2 type 7 [ 2222.987240] sd 5:0:0:0: [sdb] Attached SCSI removable disk Note the extra "reset high-speed..." lines, probably due to the kernel trying to access LUNs 1 to 5 (which the USB2 Link maps to accesses to non- existent SCSI targets 1-5). Is that harmless? [As mentioned before, the USB2 Link reports its Max LUN as 6.] > > It could/should be possible to properly support multiple targets and LUNs > > by using a similar method to the SCM USB-SCSI converters. (Those, after a > > special intitialisation request, take the target ID from the *upper* 4 bits > > of CBW byte 13.) > > Are you sure this device actually supports this? If so, what operating > system does it work on? It does definitely support that. I installed the manufacturer driver on (32-bit) Windows and looked at USBpcap captures. I also disassembled the driver. Do you think it would be worthwhile submitting a patch adding the USB2 Link to unusual-devs.h? If those reset... lines aren't acceptable I could add US_FL_SINGLE_LUN, but that would only allow it to work with a single SCSI device (set to ID 0). Or should I try and get proper/full support (multiple targets and LUNs) working first?
