On Thu, Jan 12, 2012 at 01:28:02PM -0800, Sarah Sharp wrote: > On Thu, Jan 12, 2012 at 02:55:31PM -0500, Alan Stern wrote: > > On Thu, 12 Jan 2012, Sarah Sharp wrote: > > > I'm thinking that if we get a device wake notification, the xHCI driver > > > should find the parent hub of that device and somehow kick khubd for that > > > hub. But I'd have to look and see if we could do that without > > > interfering with the URB completion for the parent hub's interrupt URB. > > > > Hmmm. As far as I can see, when a child of non-suspended non-root hub > > requests a wakeup, the hub doesn't send any special signal to the host. > > In particular, it doesn't set any port-status-change bits. Which means > > we _must_ use the notification somehow. > > > > The notification packet contains only a device address; xhci-hcd will > > have to translate that to either a device number or (ideally) a struct > > usb_device. > > 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. > > > 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. 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. 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
