]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
usb: find internal hub tier mismatch via acpi
authorDan Williams <dan.j.williams@intel.com>
Wed, 21 May 2014 01:08:40 +0000 (18:08 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 27 May 2014 23:38:52 +0000 (16:38 -0700)
commit3bfd659baec822f54e4acb0734669e671d853a35
treec44ad6218e8b028e5595dd80e9c29213a8e96298
parent8b1ba80c59fb3e77f9e1761480617d5ea9ee159c
usb: find internal hub tier mismatch via acpi

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@rowland.harvard.edu>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/usb/core/hub.h
drivers/usb/core/port.c
drivers/usb/core/usb-acpi.c
drivers/usb/core/usb.h