Re: [PATCH v3] USB: fix bug of device descriptor got from superspeed device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2012/3/24 Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>:
> On Fri, Mar 23, 2012 at 10:00:38AM +0800, Elric Fu wrote:
>> 2012/3/23 Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>:
>> > On Thu, Mar 22, 2012 at 11:13:00AM +0800, Elric Fu wrote:
>> >> When the Seagate Goflex USB3.0 device is attached to VIA xHCI
>> >> host, sometimes the device will downgrade mode to high speed.
>> >> By the USB analyzer, I found the device finished the link
>> >> training process and worked at superspeed mode. But the device
>> >> descriptor got from the device shows the device works at 2.1.
>> >> It is very strange and seems like the device controller of
>> >> Seagate Goflex has a little confusion.
>> >>
>> >> The first 8 bytes of device descriptor should be:
>> >> 12 01 00 03 00 00 00 09
>> >>
>> >> But the first 8 bytes of wrong device descriptor are:
>> >> 12 01 10 02 00 00 00 40
>> >>
>> >> The wrong device descriptor caused the initialization of mass
>> >> storage failed. After a while, the device would be recognized
>> >> as a high speed device and works fine.
>> >>
>> >> This patch will warm reset the device to fix the issue after
>> >> finding the bcdUSB field of device descriptor isn't 0x0300
>> >> but the speed mode of device is superspeed.
>> >
>> > At first I thought you missed Andiry's comment:
>> >
>> >> > +     if ((udev->speed == USB_SPEED_SUPER) &&
>> >> > +                     (udev->descriptor.bcdUSB != 0x0300)) {
>> >>
>> >> Perhaps using "< 0x0300" is better.
>> >> Maybe there will be 3.01, 3.10 devices in the future.
>> >
>> > But now I see you just shifted it:
>> >
>> >> +     if ((udev->speed == USB_SPEED_SUPER) &&
>> >> +                     (le16_to_cpu(udev->descriptor.bcdUSB) >> 8 != 0x03)) {
>> >
>> > IMO the bit shift is more difficult to understand quickly, so please use
>> > < 0x0300 instead.  Sorry for the churn for such a simple patch, but if I
>> > flubbed up on understanding it, it's likely other folks will as well.
>> >
>> > Also, it's possible that we'll have SuperSpeed devices that work at
>> > higher speeds, so perhaps they'll have a "USB 4.0" BCD.  Or perhaps USB
>> > 4.0 devices will show up as USB 3.0 devices under an xHCI host.  In that
>> > case, it will be perfectly legal to have the bcdUSB show up as 0x0400,
>> > just like USB 3.0 devices will have a bcdUSB of 0x0300 when plugged into
>> > an EHCI controller.  In short, please use < 0x0300 in your test.
>>
>> Yes, I just thought maybe we have a USB 4.0 in future. And we will have
>> to modify it again.
>>
>> I have tested the USB 3.0 device when it downgrade mode to high speed.
>> The bcdUSB of device descriptor is 0x0210. I think the device controller
>> should self-adjust the device descriptor. I am confused about "USB 3.0
>> devices will have a bcdUSB of 0x0300 when plugged into an EHCI
>> controller". Does It mean that even if the usb 3.0 device plugged into an
>> EHCI/UHCI controller the bcdUSB is always 0x3000? If yes, you will be
>> right and the "< 0x0300" is better than the bit shift.
>
> Sorry, I had that backwards.  USB 3.0 devices always show up as bcdUSB
> 0x0201 on EHCI or UHCI host controllers:
>
>        http://marc.info/?l=linux-usb&m=132632097124520&w=2
>
> However, I still think that the "< 0x0300" is easier to understand, so
> please use that.

Well, I agree with your opinion, the kernel code should be clear and easy
to understand. I'll modify it and send the v4 patch next Monday.

Best Regards,
Elric

>
> Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux