On Wed, Nov 13, 2013 at 11:11:12AM -0500, Alan Stern wrote:
> 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.
Ok, that makes sense. I'm fine with that as long as it's thoroughly
documented what all the conditions that userspace needs to meet in order
to have a port be powered off.
> > 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?
Ok, I double checked the funky hub. It has a VIA hub chipset in it, and
it has three USB 3.0 ports. lsusb shows an additional three devices:
Bus 001 Device 005: ID 2109:3431
Bus 002 Device 003: ID 2109:0810
Bus 001 Device 006: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
All four hubs report nNbrPorts=4 in their hub descriptor. So it appears
the Genesys Logic hub is downstream of the VIA Hub.
Plugging in a USB 2.0 device into the left most USB 3.0 port shows:
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 2: Dev 3, If 0, Class=hub, Driver=hub/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 2: Dev 5, If 0, Class=hub, Driver=hub/4p, 480M
|__ Port 1: Dev 6, If 0, Class=hub, Driver=hub/4p, 480M
|__ Port 2: Dev 7, If 0, Class=stor., Driver=, 480M
So it looks like the USB 3.0 portion of the hub is paired with the
first-tier USB 2.0 hub. Phew, looks like it's pretty much in compliance
with section 10.3.3, even if it steals one of the ports to be connected
to the Genesys Logic USB 2.0 hub.
It also has a Container ID that looks plausible for the USB 3.0 hub
(09210000-902d-0000-931e-000002279402), however, the paired USB 2.0
hub's bcdUSB is 2.0, not 2.1, so lsusb and the USB core don't even ask
for the BOS descriptor. Hooray, a new form of brokeness!
> > 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?
Well, that's moot, since it looks like that hub is compliant-ish enough
for your algorithm to work. Dan agreed (in conversation) to move the
external port pairing into a separate patch, so if we find it breaks too
much, we can always rip it out and leave the internal port code power
management in tact.
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
