On Thu, Jan 26, 2012 at 01:43:43PM -0500, Alan Stern wrote: > On Wed, 25 Jan 2012, Sarah Sharp wrote: > > > This patch takes care of the race condition between the Function Wake > > Device Notification and the auto-suspend timeout for this situation: > > > > Roothub > > | (U3) > > hub A > > | (U3) > > hub B > > | (U3) > > device C > > > > When device C signals a resume, the xHCI driver will set the wakeup_bits > > for the roothub port that hub A is attached to. > > It shouldn't. All it should do is call usb_super_speed_remote_wakeup() > for hub B and the port which device C is plugged into. > > > However, since USB 3.0 > > hubs do not set a link state change bit on device-initiated resume, hub > > A will not indicate a port event when polled. Without this patch, khubd > > will notice the wakeup-bits are set for the roothub port, it will resume > > hub A, and then it will poll the events bits for hub A and notice that > > nothing has changed. Then it will be suspended after 2 seconds. > > No. khubd shouldn't notice anything about hub A. Instead, it should > notice that hub B has a wakeup_bit set, so it will autoresume hub B and > then call usb_remote_wakeup() for device C while checking B's status. > > > When we notice that a port has resumed on a USB 3.0 hub, and the device > > attached to that port is a hub, set the wakeup_bits for all the child > > hub's ports. That means we'll poll the status for all ports on hub B > > to find the one that woke up, but that's better than missing a device > > remote wakeup. > > This should not be necessary. > > If the child device attached to a resumed port is a hub, it means that > hub sent the wakeup notification. The only reason for doing this is if > the hub get a connect, disconnect, or overpower event on one of its > ports. The hub_activate() routine will detect this; no extra bits need > to be set. We don't know that hub B was the one that sent the device wake notification until 2.5 seconds after it resumed. By then the roothub auto-suspend timeout will have expired, and we'll put hub A back into U3 without ever seeing the device notification. If hub A does the sane thing and immediately resumes, the window for device notification frequency is wide enough that we could miss the next device notification. Then we'll get caught in an endless loop of hub B sending a device notification, the roothub resuming, auto-suspending hub A after 2 seconds, immediately hub A wakes up because one of its ports is not in U3, we check the hub event buffer but there's no change, see there's no change, put it back in U3, etc. 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
