On Fri, Sep 21, 2012 at 11:55 PM, Alan Stern <[email protected]> wrote: > On Fri, 21 Sep 2012, Ming Lei wrote: > >> On Fri, Sep 21, 2012 at 1:04 AM, Alan Stern <[email protected]> >> wrote: >> > >> > 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 >> >> Looks it is a bug of the hub, see below. > > Like I said. > >> > 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? >> >> If a new device is connected into the '05e3:0608 Genesys Logic, Inc. >> USB-2.0 4-Port HUB' during this 10sec, the new connection can't >> trigger a remote wakeup interrupt from ehci. > > So your patch does not fix the problem, although it does make the > problem less likely to occur.
Exactly. Considered that runtime suspend may be often happened on hub devices, and status endpoint interval is about 256ms which should be a bit longer, adding the check in hub_suspend might make sense. In theory, device connection change may happen between the check and enabling remote-wakeup capability, but the period is very short. Also, I don't have a strong desire for the patch if you object to it, :-) Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
