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. 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
