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
