On Tue, Jan 31, 2012 at 02:05:08PM -0500, Alan Stern wrote: > 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. We need to disable U1 and U2 transitions before we place the device in U3 (because the hub port state machine does not list transition from U1 or U2 to U3, only from U0 to U3). We should never run into this situation. > > 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? The device continues to send Function Wake notifications every tNotification (2.5 seconds) if it has not been accessed after it sent the first notification. So we will eventually see it. > 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. Yeah, I do too, but that's a major spec change, and apparently they did know about this situation during the spec development, but still chose not to have hubs set their port link change bit on a device-initiated resume. The spec architects have basically said that section 10.8 implies that hubs need to accept the transition to U3 and immediately send resume signaling if a downstream port is not in U0. Some of them don't think a spec clarification is necessary, but they've at least agreed to add a hub certification test to ensure hubs behave this way. > > 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. Yeah, but as I said, they're probably passing on the spec errata. > > 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? Sure, I'll bring it up. > > 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. Ok, will do. 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
