On Fri, 13 Jan 2012, Sarah Sharp wrote: > > > 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. Hmmm. 10.8 says that if a hub receives wakeup signalling on a downstream port and its upstream port is in U3, then the hub will drive wakeup signalling on the upstream port. I assumed that meant the hub would send a Function Wake Notification to the host when the upstream link changed to U0, but appendix C doesn't agree. > 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. BTW, C.1.4.1 says "The FUNCTION_SUSPEND feature is also used to enable function remote wakeup". This indicates that when a device is suspended with wakeup enabled, we'd better send a Function Suspend request to each interface that is the first interface of a function and has its needs_remote_wakeup flag set. On the other hand, we should be able to skip the other interfaces. > Of course, I can't test my theory because I don't currently have enough > hubs that handle device suspend. :) In any case, it doesn't matter. 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
