On Thu, 20 Sep 2012, Ming Lei wrote: > On Thu, Sep 20, 2012 at 10:43 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > 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. > > You mean the wakeup request is remote wakeup? At least, from ehci_irq, > only PCD interrupt handles remote wakeup irq. > > But from '7.1.7.7 Resume' part of USB 2.0 spec: > > Additionally, the device can signal the system to resume operation > if its remote wakeup capability has been enabled by the USB System > Software > > At this time, the remote wakeup capability hasn't been enabled for the hub, > so the wakeup might not be generated. True, the remote wakeup capability is not enabled at the time the connect change happens. But it does get enabled before the hub is suspended, so once the hub is suspended it should issue a remote wakeup request right away. > I have tested the case by adding 'msleep(10000)' after hub_quiesce() > inside hub_suspend(), then plug a new device into the hub during the > time, but current usbcore can't find the connection. I vaguely remember seeing this same effect with one of my hubs. If a port status change occurred before the hub was suspended, the hub would not issue a remote wakeup request. This was a bug in the hub. Other hubs behaved better. > This patch can fix the problem in the above case. What happens if you put the msleep(10000) after the new check_ports_change() call? 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
