On Fri, Nov 04, 2011 at 04:17:30PM -0400, Alan Stern wrote: > 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 can try to fix it up, although I'm not sure I'll catch everything that's bothering you about the #defines. Maybe I'm not sufficiently annoyed by the duplicates. :) > 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.) Yep, that's pretty annoying. I can mail you a tarball of just the ECN if you want. (I was just going to mail you the file until I realized the PDF itself was about 1MB.) There's actually some changes on the recommendations for host-side software that's included in the updated USB 2.0 LPM ECN errata from October 11th, but I don't think that will effect hub port status bits. It mostly effects xHCI hosts that allow the LPM timeout to be set to longer values, but (AFAIK) there aren't any hosts that use the new BESL encoding yet. > > > 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. Ok, looking over the ECN, it seems that a USB 2.1 hub will report the link state change in bit 5 of the port status change bits. Andiry's USB 2.0 LPM patches only enabled LPM for devices directly attached to the roothub, so external hubs won't ever report those bits as set. However, since khubd would theoretically have to handle it anyway, there's no reason why it shouldn't have to deal with it for USB 2.0 roothub ports. The behavior when the link state change bit will be set will be slightly different for roothubs than for external hubs. External hubs will only report a change when USB 2.0 LPM is enabled for a particular port, and the roothub may report the change on port resume as well. I don't think that's a big issue though. khubd should just look for that bit being set in the get port status and just clear it. I don't think any action is needed on its part. 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
