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