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; >>>>> >>>>> Removing the SHORT_NOT_OK flag is _not_ a valid thing to do. It will >>>>> cause drivers to malfunction. >>>>> >>>>> Can you please explain this comment? >>>>> >>>>> What SCSI driver? >>>>> >>>>> When is the flag being added? >>>>> >>>>> How does it break USB drives? >>>>> >>>>> Why haven't you already reported this problem to the >>>>> appropriate maintainers? >>>>> >>>>> Alan Stern >>>>> >>>> >>>> Hi, >>>> >>>> Issue that removal of SHORT_NOT_OK flag addressed is linked to particular >>>> set of Kingston USB 3.0 flash drives (super speed) - other USB flash drives >>>> haven't had this flag set. Without this "fix", those Kingston flash drives >>>> are not being enumerated properly. >>> >>> Please explain in detail how the enumeration of these Kingston flash >>> drives fails. Or if such an explanation has already been posted, >>> please provide a link to it. >> >> Will reproduce the issue once again (w/o the fix) and run through the events. >> Issue has been noticed during early development, and addressed right away. >>> >>>> This particular line was added in the early stage of development, during >>>> enumeration process implementation. The reason why it remained in the code >>>> since is because we haven't noticed any side-effects, even with various >>>> USB devices being attached to remote MA-USB device, including flash drives, >>>> cameras, wireless mice, etc. >>> >>> Come to think of it, the SHORT_NOT_OK flag is mainly used with HCDs >>> that don't have scatter-gather support. Since your mausb driver does >>> support scatter-gather, you most likely won't encounter any problems >>> unless you go looking for them specifically. >>> >>>> The problem has been reported, and is actively being investigated. >>> >>> Where was the problem reported (URL to a mailing list archive)? Who is >>> investigating it? >> >> Ticket has been submitted to DisplayLink's internal issue-tracking system >> and is being investigated by mausb-host-devel team. > > 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. -- Regards, Vladimir.
