On Fri, 4 Nov 2011, Sarah Sharp wrote: > > > > 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. :) Send me your patch when it's ready. If anything still looks annoying, I'll update the patch. :-) > 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. Sure. And who knows, maybe someday we will support LPM for USB-2.1 hubs. > 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. Yep, that sounds right. 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
