lkml.org 
[lkml]   [2020]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [External] Re: [PATCH v5 5/8] usb: mausb_host: Introduce PAL processing
    From
    Date
    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@displaylink.com wrote:
    >>>>>>>
    >>>>>>>> Protocol adaptation layer (PAL) implementation has been added to
    >>>>>>>> introduce MA-USB structures and logic.
    >>>>>>>>
    >>>>>>>> Signed-off-by: Vladimir Stankovic <vladimir.stankovic@displaylink.com>
    >>>>>>>
    >>>>>>> ...
    >>>>>>>
    >>>>>>>> + /*
    >>>>>>>> + * 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.

    \
     
     \ /
      Last update: 2020-04-30 17:36    [W:2.360 / U:0.352 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site