On Tue, 31 Jan 2012, Sarah Sharp wrote: > Let me work on that from a spec errata angle. I think we can add a rule > after this paragraph in section 10.2.2: > > 10.2.3 Downstream/Upstream Port Link State Transitions The hub shall > evaluate the link power state of its downstream ports such that it > propagates the highest link state of any of its downstream ports to its > upstream port when there is no pending upstream traffic. U0 is the > highest link state, followed by U1, then U2, then U3, then Rx.Detect, > and then SS.Disabled. If an upstream port link state transition would > result in an upstream port link state that has been disabled by > software, the hub shall transition the upstream port link to the next > highest U-state that is enabled. The hub never automatically attempts to > transition the hub upstream port to U3. > > We can add these two paragraphs: > > If the hub's upstream port link receives a request to transition to U3 > and any of the downstream ports are in the U0 link state, the hub shall Or if any of the downstream ports are in U1 or U2. Just to be thorough. > accept the U3 transition, but immediately initiate resume signaling. > The hub shall initiate a resume regardless of whether it has been > enabled for remote wakeup. The hub shall not send a Function Wake > Device Notification, but instead shall rely on the device to send it. "the device" above is ambiguous; you can simply omit the second half of that sentence. Are you sure you don't want the hub to send a notification? It seems to me that this just repeats the mistake made in the original spec: A USB device changes a link state away from U3 without anyone telling the host about it. What if the downstream device never does send its notification? I think "downstream port changed from U3 to U0" should be treated simply as a wakeup event that cannot be disabled by software. That's basically how USB-2.0 does things. > This covers the case where a device initiates a transition from U3 to > U0, and one of its parent hubs in the path to the roothub has an > upstream port that is in U0. Software is unaware of the > device-initiated resume until the device sends the Function Wake Device > Notification, so it may attempt to place the parent hub in U3 before it > receives the notification. Strictly speaking, U0 and U3 are link states, not device states. The committee members might want to clean up the wording a little. > That way, from a software standpoint, if we suspend the active hub, it > immediately resumes. If we continue to try to suspend parent hubs, > eventually we'll detect the resume on the roothub. But I think if we > increase the default auto-suspend delay for USB 3.0 hubs to 2.5 seconds, > we should be able to get the Function Wake Device Notification before we > attempt to suspend more parent hubs. > > Of course, wasn't Oliver talking about suspending non-leaf parent hubs > immediately when their children are suspended? That could add some > delay to a device remote wakeup, but I think with the above rule in > effect, we will *eventually* become aware of the wakeup. Yes, although we should strive to minimize delays. Ultimately, though, we're stuck with the devices' delays in sending their notifications. > > (Here's a relevant question: What should a hub do if it receives a data > > packet on a downstream port while its upstream link is in U3? > > Apparently nobody knows.) > > Well, assuming software isn't suspending the device while a transfer is > active, the only packet a suspended hub could receive would be an > asynchronous Device Notification, i.e. a Function Wake notification. > And yes, I don't think the spec says what the hub should do in that > case. The hub has to have some sort of buffering for device > notifications, in case its receiving traffic on its upstream port and it > receives a device notification on its downstream port, or if two devices > send a device notification at the same time. I just don't think there's > any rule for forwarding those notifications after the hub upstream port > resumes. Would you want to add such a rule as part of your erratum update? > Ok, that makes sense. I'll send an updated patchset today or tomorrow. Patches 1-6 and 9 were uncontroversial. 7 and 8 are the only ones that need any alteration. 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
