On Tue, 12 Nov 2013, Sarah Sharp wrote: > > No, but that last one can be subdivided into: > > - implement hotplug vs hardwired policy > > I think the original agreement when the USB 2.0 port power off work > went in was that hotplug vs hardwired shouldn't make a difference in the > kernel. It would be up to userspace to read the port connection type, > and decide whether to enable port power off. > > What in-kernel policy were you thinking of? There's the policy which Dan identified a need for: If power-off is enabled for port then the peer port has to be powered off also. > I don't think we should try to coordinate pairing USB 2.0 and USB 3.0 > ports on external hubs that aren't described by ACPI. I think there's > far too many corner cases, especially with the introduction of a tier > mismatch, either at the roothub or within another USB 3.0 hub. > > I have a USB 3.0 hub (not with me right now), which has either three or > four USB 3.0 ports exposed, and seven USB 2.0 ports. The OS sees it as > one USB 3.0 hub and two USB 2.0 hubs chained together. My guess is that > the manufacturer wanted to say they had a "seven port USB 3.0 hub", but > only four-port USB 3.0 hub chips were available, and they didn't have > room in the hardware design or didn't want to pay for the second USB 3.0 > hub chip. > > There's no real way to tell how port power is routed across the ports > without doing some physical layout tests. I could see how they could > meet the requirement in section 10.3.3 by pairing the USB 3.0 ports with > either USB 2.0 hub. > > If they wanted to attach to the parent hub, they could physically expose > three USB 3.0 ports, leave one port unexposed and not connected to any > physical wires, and say the USB 3.0 hub has four ports. That ensures > compatibility with section 10.3.3 while still allowing the USB 2.0 port > to be used by the second-tier hub without exposing a USB 3.0-only port. > > However, that's technically violating the spirit of section, 10.3.3, and > it's probably easier to pair the USB 3.0 ports with the child USB 2.0 > hub. That would also allow them to expose all four USB 3.0 ports. In fact, it seems like this hub design is in actual violation of Section 3.2.6.2 (not just the spirit): A USB 3.0 hub connects upstream as two devices; a SuperSpeed hub on the SuperSpeed bus and a USB 2.0 hub on the USB 2.0 bus. Your hub connects as _two_ USB 2.0 hubs on the USB 2.0 bus, thus appearing upstream as _three_ devices. Does it provide a Container ID BOS descriptor that we could use to determine the true port peering? > If the USB 3.0 ports are paired with the second-tier hub, I think Alan's > algorithm for finding paired external hubs fails. In this case, the > peer for the USB 3.0 hub isn't the USB 2.0 hub that's the same depth > down in the external topology, but the next hub downstream. Yes, the algorithm fails for hubs the violate the spec. That's to be expected. The question is: How far do you want to go to support such things? 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
