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]

 



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.

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