On Wed, 1 Feb 2012, Sarah Sharp wrote: > USB 3.0 hubs don't have a port suspend change bit (that bit is now > reserved). Instead, when a host-initiated resume finishes, the hub sets > the port link state change bit. > > When a USB 3.0 device initiates remote wakeup, the parent hubs with > their upstream links in U3 will pass the LFPS up the chain. The first > hub that has an upstream link in U0 (which may be the roothub) will > reflect that LFPS back down the path to the device. > > However, the parent hubs in the resumed path will not set their link > state change bit. Instead, the device that initiated the resume has to > send an asynchronous "Function Wake" Device Notification up to the host > controller. Therefore, we need a way to notify the USB core of a device > resume without going through the normal hub URB completion method. > > First, make the xHCI roothub act like an external USB 3.0 hub and not > pass up the port link state change bit when a device-initiated resume > finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that > we can tell the difference between a port coming out of the U3Exit state > (host-initiated resume) and the RExit state (ending state of > device-initiated resume). > > Since the USB core can't tell whether a port on a hub has resumed by > looking at the Hub Status buffer, we need to introduce a bitfield, > wakeup_bits, that indicates which ports have resumed. When the xHCI > driver notices a port finishing a device-initiated resume, we call into > a new USB core function, usb_wakeup_notification(), that will set > the right bit in wakeup_bits, and kick khubd for that hub. > > We also call usb_wakeup_notification() when the Function Wake Device > Notification is received by the xHCI driver. This covers the case where > the link between the roothub and the first-tier hub is in U0, and the > hub reflects the resume signaling back to the device without giving any > indication it has done so until the device sends the Function Wake > notification. > > Change the code in khubd that handles the remote wakeup to look at the > state the USB core thinks the device is in, and handle the remote wakeup > if the port's wakeup bit is set. > > This patch only takes care of the case where the device is attached > directly to the roothub, or the USB 3.0 hub that is attached to the root > hub is the device sending the Function Wake Device Notification (e.g. > because a new USB device was attached). The other cases will be covered > in a second patch. Both this patch and the next one look good. You might even consider merging them into a single patch, because 8/9 mostly just changes code that was added in 7/9. 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
