On Fri, Jan 13, 2012 at 11:34:04AM -0500, Alan Stern wrote: > On Thu, 12 Jan 2012, Sarah Sharp wrote: > > > > The xHCI host translates that device address into a slot ID and puts > > > that into the Device Notification Event TRB that it passes up to the > > > xHCI driver. We can use the slot ID to map to the struct usb_device. > > Okay, good. > > > > > We'll create a hub->wakeup_bits bitflag array, and hub.c > > > > can export a function for xhci-hcd to call that will set the > > > > appropriate bitflag and kick khubd. > > > > Say that the USB tree looks like this: > > > > host > > | > > | U0 > > | > > hub A > > | > > | U3 > > | > > hub B > > | > > | U3 > > | > > hub C > > | > > | U3 > > | > > device D > > > > Device D sends a remote wakeup. According to the USB 3.0 bus spec, > > section C.1.4.5, the first hub not in U3 (which is hub A) will reflect > > the LFPS signaling back to device C. Now hub B, hub C, and device D are > > all in U0, but the USB core thinks they are still suspended. Then the > > xHCI driver receives a device wake notification sent by device D. > > It should receive notifications from hubs B and C as well. Not that > they will matter. Why would hubs B and C send a device notification? They're not the ones signaling the remote wakeup, and there's been no disconnects, connects, or overcurrent events, so there's nothing they've been programmed to send a remote wakeup for. I can't find any mention of Function Wake device notifications in the hub section, aside from the wake bits. Appendix C just says that the device that initiated the resume signaling needs to send the notification. Of course, I can't test my theory because I don't currently have enough hubs that handle device suspend. :) > > Does the USB core need to auto-resume all the parent hubs (starting from > > hub A), or can it just call kick_khubd() with hub C, and count on all > > the parents getting resumed when usb_autopm_get_interface() is called in > > hub_events()? I don't know how the runtime PM core works for this. > > usb_autopm_get_interface() utilizes the PM runtime core API, which > guarantees that whenever a device is resumed, so is its parent (if the > parent was suspended). Thus, we'll get autoresume calls for the > intermediate hubs before the resume call for the leaf device. Ok, good, that's what I thought. 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
