On Wed, 5 Mar 2014, Dan Williams wrote:
> > > When we find port location data for a port then we assume that the
> > > firmware will also describe its peer port. This allows the
> > > implementation to only ever set the peer once. This leads to a question
> > > about what happens when a pm runtime event occurs while the peer
> > > associations are still resolving. Since we only ever set the peer
> > > information once, a USB3 port needs to be prevented from suspending
> > > while its ->peer pointer is NULL (implemented in a subsequent patch).
> >
> > Strictly speaking, the peer information could be set more than once (if
> > the hub driver gets unbound and rebound to an internal hub).
>
> Once per lifetime of the hub object.
No, not even that. Suppose usb1-port1 is the peer of usb2-port1. If
the hub driver is unbound from usb1, the peering relation is destroyed.
When the hub driver is rebound, the peering relation is recreated.
This all happens during the lifetime of usb2's hub object.
> > I took a closer look at the example in Appendix D of the xHCI spec.
> > Somewhat distressingly, the sample ACPI code in D.1.1 does not include
> > _PLD information for the internal (not user-visible) ports. Thus, of
> > the four root-hub ports in Figure 128, there is _PLD data only for
> > HCP4. This would lead us to assume that ports HCP1 and HCP3 are peers,
> > but they aren't. (And we would fail to realize that HCP3 and IP3 _are_
> > peers.)
> >
> > In this case the error would be harmless, because HCP1 is not
> > connectable. But there could be other cases where it would matter.
> > (In theory, a platform could hard-wire a high-speed device to the
> > HS port _and_ a SuperSpeed device to the corresponding SS port! I
> > don't know if this would comply with the spec -- but manufacturers
> > wouldn't let a little drawback like that affect their designs.)
>
> Indeed.
>
> > (It's also somewhat distressing that the sample _UPC data for ports
> > HCP1 and HCP2 has the "connectable" attributes backwards! In addition,
> > the example in Figure 128 disobeys the requirement in 4.24.2.2 that
> > when an embedded hub is present, a tier mismatch is not allowed!)
> >
> > In order to make this work, maybe we need to look at the USB2 xHCI
> > Supported Protocol Capability Integrated Hub Implemented (IHI) flag
> > (section 2.24.2.1).
>
> Possibly. However, at this point I would defer doing anything more
> complicated until we actually start to see platforms land with tier
> mismatch. In my testing I have yet to see either tier mismatch, or
> root/internal hubs where hub_is_port_power_switchable() returned true.
Okay, we'll start slowly and build up to more complicated stuff as the
need arises.
> > The logic here and in usb_acpi_get_connect_type above seems wrong.
> > The ACPI spec states that _PLD data need not be available for ports
> > that aren't visible to the user. (See the example code in section 9.14
> > of the ACPI-3.0 spec.)
> >
> > So do we want to treat absence of _PLD as meaning the connect type is
> > unknown? It could very well be hard-wired.
>
> It very well could be. I refactored that routine to keep the same
> behavior and missed that the original implementation was erroring out
> too early ('pld' == NULL). Nothing in the kernel currently cares about
> the distinction of non-visible ports. Yes, there was a plan to
> automatically power off such ports, but no patches being proposed
> currently that exploit that classification. I think we can delay a
> patch to fix this up until after the current round of port power control
> patches land.
All right.
> 8<--------
> Subject: usb: find internal hub tier mismatch via acpi
>
> From: Dan Williams <dan.j.williams@xxxxxxxxx>
>
> ACPI identifies peer ports by setting their 'group_token' and
> 'group_position' _PLD data to the same value. If a platform has tier
> mismatch [1] , ACPI can override the default (USB3 defined) peer port
> association for internal hubs. External hubs follow the default peer
> association scheme.
>
> Location data is cached as an opaque cookie in usb_port_location data.
>
> Note that we only consider the group_token and group_position attributes
> from the _PLD data as ACPI specifies that group_token is a unique
> identifier.
>
> When we find port location data for a port then we assume that the
> firmware will also describe its peer port. This allows the
> implementation to only ever set the peer once. This leads to a question
> about what happens when a pm runtime event occurs while the peer
> associations are still resolving. Since we only ever set the peer
> information once, a USB3 port needs to be prevented from suspending
> while its ->peer pointer is NULL (implemented in a subsequent patch).
>
> There is always the possibility that firmware mis-identifies the ports,
> but there is not much the kernel can do in that case.
>
> [1]: xhci 1.1 appendix D figure 131
> [2]: acpi 5 section 6.1.8
>
> [alan]: don't do default peering when acpi data present
> Suggested-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx>
> --- a/drivers/usb/core/port.c
> +++ b/drivers/usb/core/port.c
> @@ -182,8 +182,42 @@ static void unlink_peers(struct usb_port *left, struct usb_port *right)
> }
>
> /*
> - * Set the default peer port for root hubs, or via the upstream peer
> - * relationship for all other hubs
> + * For each usb hub device in the system check to see if it is in the
> + * peer domain of the given port_dev, and if it is check to see if it
> + * has a port that matches the given port by location
> + */
> +static int match_location(struct usb_device *peer_hdev, void *p)
> +{
> + int port1;
> + struct usb_hcd *hcd, *peer_hcd;
> + struct usb_port *port_dev = p, *peer;
> + struct usb_hub *peer_hub = usb_hub_to_struct_hub(peer_hdev);
> + struct usb_device *hdev = to_usb_device(port_dev->dev.parent->parent);
> +
> + if (!peer_hub)
> + return 0;
> +
> + hcd = bus_to_hcd(hdev->bus);
> + peer_hcd = bus_to_hcd(peer_hdev->bus);
> + /* peer_hcd is provisional until we verify it against the known peer */
> + if (peer_hcd != hcd->shared_hcd)
> + return 0;
I suppose if you wanted to be really clear about this, you could call
them "other_hdev", "other_hcd", and "other_hub". Until this test is
passed, you don't know that they are actually peers to hdev and hcd.
But I'm okay with this the way it is.
Acked-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
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
