On Fri, 4 Nov 2011, Sarah Sharp wrote: > > > But USB_PORT_STAT_C_PORT_LINK_STATE is never exposed to the USB core for > > > USB 2.0 roothubs, since external USB 2.0 hubs don't have that bit. So > > > it needs to be cleared internally in the xHCI driver. > > > > Hmmm. It looks like include/linux/usb/ch11.h also needs to be fixed > > up. Table 11-17 in the USB-2.0 spec defines port feature numbers only > > up to 22; the remaining entries (23 - 30) must be introduced elsewhere. > > In addition, some of the port feature #define's in that file are > > duplicates. (And the ones that aren't duplicates are slightly different from the names in the USB-3.0 spec...) Do you want to fix this up? I don't seem to have any copies of the USB-2.0 link power management ECN. (And www.usb.org forces you to download an archive of _all_ the spec files instead of allowing you to pick and choose the ones you want, argh.) > > Anyway, once that's done we could add code to handle > > USB_PORT_STAT_C_PORT_LINK_STATE to the hub driver. > > So you don't mind adding code to the hub driver that will only run for > the roothub? I thought the idea was to treat roothubs exactly like > external hubs, which is why there's that horrible layering abstraction > of khubd submitting URBs that just get passed down to the host > controller driver. Not that I *mind* the hub driver handling the link > state change for USB 2.0 and USB 3.0 ports... Why wouldn't an external USB-3 hub report USB_PORT_STAT_C_LINK_STATE in its wPortChange value? 10.14.2.6.2 seems to say that external hubs should set this bit as needed. The fact that a xHCI USB-2 root hub might report it as well would then be handled for free. Alan Stern -- 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
