On Wed, 5 Mar 2014, Dan Williams wrote:
> 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).
Strictly speaking, the peer information could be set more than once (if
the hub driver gets unbound and rebound to an internal hub).
> 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>
> @@ -182,8 +182,40 @@ 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 *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;
> +
> + peer_hcd = bus_to_hcd(hdev->bus)->shared_hcd;
> + if (!peer_hcd || peer_hcd != bus_to_hcd(peer_hdev->bus))
> + return 0;
This is correct but a little difficult to follow. How about something
along these lines instead?
hcd = bus_to_hcd(hdev->bus);
peer_hcd = bus_to_hcd(peer_hdev->bus);
if (peer_hcd != hcd->shared_hcd)
return 0;
> @@ -192,7 +224,17 @@ static void find_and_link_peer(struct usb_hub *hub, int port1)
> struct usb_device *peer_hdev;
> struct usb_hub *peer_hub;
>
> - if (!hdev->parent) {
> + /*
> + * If location data is available then we can only peer this port
> + * by a location match, not the default peer (lest we create a
> + * situation where we need to go back and undo a default peering
> + * when the port is later peered by location data)
> + */
> + if (port_dev->location) {
> + /* we link the peer in match_location() if found */
> + usb_for_each_dev(port_dev, match_location);
> + return;
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.)
(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).
> @@ -194,7 +190,16 @@ static struct acpi_device *usb_acpi_find_companion(struct device *dev)
> if (!adev)
> return NULL;
> }
> - usb_acpi_check_port_connect_type(udev, adev->handle, port1);
> + handle = adev->handle;
> + status = acpi_get_physical_device_location(handle, &pld);
> + if (ACPI_FAILURE(status) || !pld)
> + return adev;
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.
> --- a/drivers/usb/core/usb.h
> +++ b/drivers/usb/core/usb.h
> @@ -175,6 +175,10 @@ extern void usbfs_conn_disc_event(void);
> extern int usb_devio_init(void);
> extern void usb_devio_cleanup(void);
>
> +/* firmware specific cookie identifying a port's location */
> +#define USB_PORT_LOCATION_NONE 0
This #define isn't used anywhere. We don't need it.
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
