On Tue, 20 Jul 2010, Sarah Sharp wrote: > > What about the Set-Port-Feature(PORT_LINK_STATE) SS.Disabled request > > mentioned in 10.3.1.9 and 10.14.2.10? Does this cause the device to > > start using the USB-2 bus? > > It seems to cause the device to start using the USB 2.0 bus. Section > 7.5 says, "SS.Disabled is a link state where SuperSpeed connectivity is > disabled and the link may operate under USB 2.0 mode." and section > 10.3.1.9 says "DSPORT.Disabled A port transitions to this state when the > port receives a SetPortFeature(PORT_LINK_STATE) SS.Disabled request. In > this state, the portâ??s link shall be in the SS.Disabled state." > > But I'm trying to figure out if it's equivalent to disabling a USB 2.0 > port. Figure 10-19 shows that the only way for a downstream port on a > hub to come out of SS.Disabled is for the hub to receive a > SetPortFeature(PORT_LINK_STATE) = Rx.Detect request. Section 7.5.1.2 > also says > > "Exit from SS.Disabled: > â?¢ A downstream port shall transition to Rx.Detect when directed. > â?¢ An upstream port shall transition to Rx.Detect only when VBUS > transitions to valid or a USB 2.0 bus reset is detected." > > So that sounds like the only way to re-enable a USB 3.0 port is for > software to manually enable it. Looks like you're right. (And it _really_ looks like the USB 3.0 spec is wayyyy over-complicated...) > I'm trying to see how that fits in with the statement you made about > what happens when a USB 2.0 port is disabled and then a new device is > connected to it: > > "What happens is the hub enables the port automatically at the end of a > successful reset, and the host resets the port when a connect change > occurs." > > By "the host", do you mean the host controller or the operating system? > Which initiates the port reset? The OS. When I say "host" I mean the host system, in the same way as the virtualization people do. When I want to refer to the controller, I call it the "host controller". > I'm confused about how the re-connect works with a USB 3.0 hub, since > section 7.4.2 says that warm or hot reset is not allowed when the port > is in the SS.Disabled state. > > Perhaps John or someone working on a USB 3.0 hub can help clear up this > confusion? > > > > So it's probably better to treat all USB 3.0 ports (on roothubs and > > > external hubs) as if they can't be disabled. > > > > Undoubtedly. To the greatest extent possible, root hubs should be > > treated the same as external hubs. > > > > This still leaves open some of the other cases. They seem to fall into > > two categories: > > > > We want to ignore a device. Is it okay just to leave the > > port alone? In USB-2 it isn't, because of the possibility > > for address conflicts. Isn't this true in USB-3 also? What > > happens if there's more than one device using address 0? > > Also, it would be good if whatever we do forces the device to > > go into a low-power state. > > When a USB 3.0 device is issued a set address command, the route string > is used. So it's fine to have multiple USB 3.0 devices using address 0, > because the route string is unique per device. (Unless the roothub has > more than 15 ports on it, which is unlikely.) So I think it's ok to not > disable the port when we want to ignore the device. Of course, it would be necessary to insure that we never send any request other than Set-Address to a device using address 0, unless that request also uses the route string. What about the possibility of multiple devices using some address other than 0? > > We want a device to be re-enumerated because of a firmware > > change. This is really much the same as the first case, > > although now we don't care about low-power states since the > > device is going to accessed again in the near future. > > In this case, can you just reset the device? Is the device expecting > the port to be disabled? Reset alone would be enough. The port doesn't have to be disabled, _provided_ you don't mind the idea of a live device using an address the kernel has forgotten about. With USB-2 we _do_ mind. 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
