On Wed, Jul 21, 2010 at 10:05:02AM -0400, Alan Stern wrote: > 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...) Yeah. I just closed my ears and went "la la la" whenever the link chapter folks started talking. They would go on for ages. > > > > 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? All transfers are routed over the USB 3.0 bus, so they could do link power management properly. In looking over the link section, the only headers that don't contain routing info are link management packets, and those are only sent directly between an upstream and a downstream port (and are consumed by the recipient). There's no routing for the isochronous timestamp packet, but that's routed through all links that aren't in a low power state, not to a particular device. So a transfer is always routed to a particular device based on the route string. > > > 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. In the cases where the kernel wants to ignore the device, does it deallocate the device structure? If so, the USB core will call the host controller's free_dev() function, and xHCI host controller will mark that device address as being free. The next device that gets plugged in might get that address. But the route string should be different, so the misbehaving device should never see packets for its old address. I think we're fine if USB 3.0 ports never get disabled. 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
