On Tue, Oct 19, 2021 at 12:15:09PM +0200, mark_k@xxxxxxxxx wrote: > Hi, > > 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? > However in order to access multiple targets and LUNs, the USB2 Link uses > byte 13 of the command block wrapper in a special way. > > Normally CBW byte 13 has bCBWLUN in bits [3:0] with bits [7:4] reserved. > The USB2 Link expects the target ID in bits [3:0] and LUN in bits [7:4]. > The advantage of that is, it should be possible to access multiple targets > without needing to modify the USB mass storage driver. (It returns 0x06 to > a Get Max LUN request since its SCSI ID is hard-coded to 7.) > > Being able to access non-zero actual LUNs would of course require changes > to the driver. > > I'm just wondering, how does the usb-storage driver handle these cases: > > - (What it thinks are) LUNs are not contiguous. Suppose the user has two > SCSI devices in the chain, one with ID 0 the other with ID 3. Would it > scan LUNs (which map to separate targets) 1, 2, 4, 5 and 6? Or would it > give up on getting no response from LUN 1? > > - "LUN" 0 is not present. E.g. where the connected SCSI devices have IDs 1 > and 3. > > - When different "LUNs" are completely different devices (e.g. one a > CD-ROM, another a hard disk, another a tape drive). > 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? thanks, greg k-h
