On Thu, 20 Sep 2012, Ming Lei wrote: > It is very common that hub status endpoint has a long 'bInterval', > for example, it may be 11(128ms for HS device) or 12(256ms for HS > device), so the device connection change may be reported a bit > later via status pipe. In fact, the USB spec requires FS hubs to have bInterval set to 255 and HS hubs to have bInterval set to 12. > So there may have device connection changes happened already on the > downstream ports, and no status URB completes when it is killed > in hub auto-suspend path, which may miss the connection change event > and let hub suspend successfully. > > This patch introduces check_ports_changed() to check port change event > in auto-suspend path, and recover hub state and return -EBUSY if > change events are found. > > The disadvantage is that some delay may be introduced in hub auto-suspend > path. This is not necessary. If a connect change occurred but hadn't been reported when the hub was suspended, then the hub will issue a wakeup request. The connect change will not get lost. 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
