On Wed, 2010-03-03 at 18:09 -0500, Alan Stern wrote: > On Wed, 3 Mar 2010, Sarah Sharp wrote: > > > > This can't be right. There _is_ no SUPERSPEED feature; the macro > > > definition in hub.h is bogus. (For that matter, there is no HIGHSPEED > > > feature either -- that ought to be cleaned up.) Note that (1 << > > > USB_PORT_FEAT_SUPERSPEED) is actually equal to USB_PORT_STAT_TEST -- > > > which is certainly not what you want. > > > > Hmm, well, I just copied the high speed case when I created > > USB_PORT_FEAT_SUPERSPEED. I really had no idea what the hub driver was > > doing. Maybe you can relook at the xhci-hub.c code and the > > modifications I made to khubd? > > Okay. One thing might be troublesome: The definition of > PORT_STAT_POWER is wrong for USB-3.0. (What were the USB-IF members > smoking when they changed that bit from its USB-2.0 position?) > Luckily, I don't think it gets used anywhere. > > People tend to fall into the trap of thinking there's a 1-1 relation > between port feature values and the corresponding port status bit > positions, given by a simple bit shift. That's not true in general, > and with USB-3.0 it's a lot less true than it used to be. > > > > I'm not sure exactly what is the right thing to test here; certainly > > > you need to check whether the hub supports USB-3.0. However it's not > > > clear exactly how external hubs will behave; the USB-3.0 spec says that > > > hubs are the only devices allowed to function at high-speed and > > > SuperSpeed at the same time, but it doesn't explain what that entails. > > > > AFAIK, you'll see two hub attaches, one is a SuperSpeed only hub, and > > the other is a USB 2.0 hub. When you unplug the USB 3.0 hub, both of > > the devices go away. > > So a single physical device will show up as two separate devices on the > same bus? And it will end up getting assigned two separate addresses? > In that case what I said was correct; the test should be for whether > the hub is USB 3.0 instead of checking the port speed. That's because, > as you said, the USB-3.0 incarnation of the hub is SuperSpeed only. Thanks for the comments. I don't know how external USB3.0 hub behaves since I don't have one, but the xHC root hub contains both USB2 and USB3 protocol ports. I only need to apply to the USB3 ports in the root hub. In this case should I give a test for the hub rather than the port? I didn't notice (1 << USB_PORT_FEAT_SUPERSPEED) is equal to USB_PORT_STAT_TEST, thanks for the remind. But I just need a flag here. Can we just use a workaround here? re-define USB_PORT_FEAT_SUPERSPEED to make no conflict and I'll refine the patch with FIXME and proper comment in code. When there is better solution we can remove it. We need this workaround because without the patch, if xHCI bus suspend/resume is implemented, even if you do nothing in them, the USB3.0 device will fail to be recognized. That sounds like a critical issue. -- Thanks, Andiry -- 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
