On 30.4.20. 17:18, Alan Stern wrote: > On Thu, 30 Apr 2020, Vladimir Stankovic wrote: > >> On 26.4.20. 22:56, Alan Stern wrote: >>> On Sun, 26 Apr 2020, Vladimir Stankovic wrote: >>> >>>> On 26.4.20. 16:31, Alan Stern wrote: >>>>> On Sun, 26 Apr 2020, Vladimir Stankovic wrote: >>>>> >>>>>> On 26.4.20. 02:32, Alan Stern wrote: >>>>>>> On Sat, 25 Apr 2020 vladimir.stankovic@xxxxxxxxxxxxxxx wrote: >>>>>>> >>>>>>>> Protocol adaptation layer (PAL) implementation has been added to >>>>>>>> introduce MA-USB structures and logic. >>>>>>>> >>>>>>>> Signed-off-by: Vladimir Stankovic <vladimir.stankovic@xxxxxxxxxxxxxxx> >>>>>>> >>>>>>> ... >>>>>>> >>>>>>>> + /* >>>>>>>> + * Masking URB_SHORT_NOT_OK flag as SCSI driver is adding it where it >>>>>>>> + * should not, so it is breaking the USB drive on the linux >>>>>>>> + */ >>>>>>>> + urb->transfer_flags &= ~URB_SHORT_NOT_OK; > > ... > >>> Okay. What SCSI driver does the comment refer to? Is it something >>> internal to DisplayLink or is it part of the regular Linux kernel? >>> >>> Alan Stern >>> >> Hi, >> >> Comment was related to the SCSI driver that's part of regular Linux kernel - >> once the remote USB flash drive gets enumerated by host, it would appear as >> directly attached to host and then handled by the kernel. >> >> With current implementation, following messages are being logged: >> >> scsi 3:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6 >> sd 3:0:0:0: Attached scsi generic sg2 type 0 >> >> after which the flash drive is usable/accessible from host side. > > More context please. Without the log messages preceding this one we > can't tell whether the device is using the usb-storage driver or the > uas driver. > > Also, what makes you think the driver is setting the SHORT_NOT_OK flag > at the wrong time? In fact, how can there be a wrong time? > SHORT_NOT_OK is a valid flag to use with any control or bulk URB. > > Alan Stern > The comment is clearly wrong - as mentioned earlier, this fix was added in early development phase and I guess that implementer was not clear on how the particular flag was added. Investigation is ongoing around proper fix for this. Anyhow, it is a usb-storage driver related to this - here is usb-related log snippet: usb 3-1.1.2: new high-speed USB device number 5 using mausb_host_hcd_dev usb 3-1.1.2: New USB device found, idVendor=0951, idProduct=1666 usb 3-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-1.1.2: Product: DataTraveler 3.0 usb 3-1.1.2: Manufacturer: Kingston usb 3-1.1.2: SerialNumber: 0C9D9210E304E311095E087A usb-storage 3-1.1.2:1.0: USB Mass Storage device detected scsi host3: usb-storage 3-1.1.2:1.0 scsi 3:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6 Attached scsi generic sg2 type 0 [sdb] 30277632 512-byte logical blocks: (15.5 GB/14.4 GiB) As can be seen, USB flash attached to remote device is properly enumerated via MA USB. Without the fix, usb driver is not able to read USB descriptors, ending up in USB storage not being accessible. -- Regards, Vladimir.
