On Fri, 27 Jan 2012, Sarah Sharp wrote: > > Do we really need to worry about this? The worst that can happen is > > the parent hub suspends, then the device requests another wakeup and > > sends another notification. > > The device will send another device notification, but it won't attempt > to signal a resume, because from its standpoint, the link state is still > in U0. Here's why: > > All USB 3.0 hubs are powered by wall worts. USB 2.0 hubs suspend after > they haven't seen an SOF for a period of time, but they got rid of SOFs > for USB 3.0 devices (too much power consumption). USB 3.0 devices and > hubs communicate via link commands to transition between U0, U1, U2, and > U3. In this case, the child device thinks its link is in U0, and will > continue to do so until it gets an LGO_U3 request and responds with an > LAU (link accept U-state). But the parent hub only sends an LGO_U3 if > SW set that port's link state to U3. Obviously SW won't set that link > state to U3 because we think the device is still suspended. Are you certain this requires software intervention? As an example, 10.3.1.5 gives conditions under which a hub's downstream link will automatically go back to U3 from U0. (See the second-to-last paragraph in 10.4.2.6.) No software activity is needed. Of course, that's not the case you're talking about here. 10.3.1.5 describes what happens when a device is plugged into a suspended hub, and you're talking about what happens when a hub is suspended while one of its children is active. > So what does the USB 3.0 hub do if it receives an LG0_U3 request on its > upstream port, and one of its downstream ports is in a higher-power link > state (U0 in our case)? > > The USB 3.0 spec is ambiguous about this behavior of the hub. The smart > thing to do would be accept the LGO_U3 command and immediately signal a > resume. Or else accept the command and send a similar command to the downstream port. > However, in talking with the hub chapter owner, he says there > is some ambiguity about whether the hub will do that, or simply ignore > the LGO_U3 command. > > If it does ignore the LGO_U3 command, the results are pretty disastrous. > After automatically trying the U3 transition three times, the parent hub > will place the port in SS.Inactive, and signal a port status change > event to SW. Then we have to issue a warm reset on that port, and I > think that means we'll have to re-enumerate the device. And there doesn't seem to be much we can do to prevent this, if the hub doesn't cooperate. > So I would like to avoid this ambiguity by starting the resume from the > roothub down when the roothub indicates there was resume signaling. Of Okay, the root hub knows that it resumed one of its ports, but it doesn't know where the remote wakeup request came from. I guess the thing to do is interpret the root hub's data as a wakeup request, and have hub_activate()'s HUB_RESUME case check for downstream ports in U0. > course, that doesn't cover the case where the link between the roothub > and the first-tier hub is in U0, like so: > > roothub > | (U0) > hub A > | (U3) > hub B > | (U3) > device C > > If device C signals a remote wakeup, hub A will reflect the resume > signaling, but not give any indication to the host SW that it has done > so. I'm working to see if we can get a spec errata or hub compliance > test to make sure that the hubs have the sane behavior of accepting the > LGO_U3 and immediately transitioning back to U0. There are no > certified hubs out there yet, but you can certainly find them online at > Amazon and Newegg. I have no idea if they actually handle U3, or > they'll just ignore the LGO_U3, or they'll do the sane thing of > immediately resuming. Okay. It looks like we can't do anything about this at the moment. > > Also, what you're saying makes no sense. We have no way to know that > > the parent hub should be prevented from suspending, because we don't > > realize that anything special has happened until we receive the > > notification. > > We do, if the link between hub A and the roothub is in U3. Then the > roothub will reflect the resume signaling, the xHCI driver gets a port > status change event, and it can call usb_super_speed_remote_wakeup() for > the roothub. You don't need to call that routine. Just make khubd interpret the C_PORT_LINK_STATE status for root hub ports as indicating a wakeup event. That's the bit which indicates the root hub reflected the resume signal, right? We can use usb_super_speed_remote_wakeup() strictly for handling Function Wakeup device notifications. In fact, you might rename it to usb_wakeup_notification(). I don't have time now to respond more fully. Can you flesh out these ideas? 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
