linux-toradex.git/drivers/usb/core/usb-acpi.c, branch v5.16-rc3

usb: core: Use ACPI_SUCCESS() at appropriate places

2020-02-19T10:08:52+00:00

Use ACPI_SUCCESS() to replace !ACPI_FAILURE(), this avoids additional operation.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200218191717.73512-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: core: Make use of acpi_evaluate_object() status

2020-02-19T10:08:52+00:00

Compiler is not happy about dangling variable:

.../core/usb-acpi.c: In function ‘usb_acpi_get_connect_type’:
.../core/usb-acpi.c:90:14: warning: variable ‘status’ set but not used [-Wunused-but-set-variable]
   90 |  acpi_status status;
      |              ^~~~~~

Make use of it by checking the status and bail out in case of error.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200218185207.62527-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: assign ACPI companions for embedded USB devices

2019-01-25T07:46:26+00:00

USB devices permanently connected to USB ports may be described in ACPI
tables and share ACPI devices with ports they are connected to. See [1]
for details.

This will allow us to describe sideband resources for devices, such as,
for example, hard reset line for BT USB controllers.

[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/other-acpi-namespace-objects#acpi-namespace-hierarchy-and-adr-for-embedded-usb-devices

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Rajat Jain  (changed how we get the usb_port)
Acked-by: Greg Kroah-Hartman 
Tested-by: Sukumar Ghorai 
Signed-off-by: Marcel Holtmann

usb: split code locating ACPI companion into port and device

2019-01-25T07:46:26+00:00

In preparation for handling embedded USB devices let's split
usb_acpi_find_companion() into usb_acpi_find_companion_for_device() and
usb_acpi_find_companion_for_port().

Signed-off-by: Dmitry Torokhov 
Signed-off-by: Rajat Jain 
Acked-by: Greg Kroah-Hartman 
Tested-by: Sukumar Ghorai 
Signed-off-by: Marcel Holtmann

usb: clarify ACPI spec version and section number for _UPC & _PLD

2018-03-09T17:37:10+00:00

ACPI spec inserts sections for new features frequently and section
numbers are changed. It is easy to refer to ACPI spec if ACPI version
is available in comments.

There are no functional changes.

Signed-off-by: Alex Hung 
Signed-off-by: Greg Kroah-Hartman

USB: core: Remove redundant license text

2017-11-04T10:55:39+00:00

Now that the SPDX tag is in all USB files, that identifies the license
in a specific and legally-defined manner.  So the extra GPL text wording
can be removed as it is no longer needed at all.

This is done on a quest to remove the 700+ different ways that files in
the kernel describe the GPL license text.  And there's unneeded stuff
like the address (sometimes incorrect) for the FSF which is never
needed.

No copyright headers or other non-license-description text was removed.

Signed-off-by: Greg Kroah-Hartman 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

USB: add SPDX identifiers to all remaining files in drivers/usb/

2017-11-04T10:48:02+00:00

It's good to have SPDX identifiers in all files to make it easier to
audit the kernel tree for correct licenses.

Update the drivers/usb/ and include/linux/usb* files with the correct
SPDX license identifier based on the license text in the file itself.
The SPDX identifier is a legally binding shorthand, which can be used
instead of the full boiler plate text.

This work is based on a script and data from Thomas Gleixner, Philippe
Ombredanne, and Kate Stewart.

Cc: Thomas Gleixner 
Cc: Kate Stewart 
Cc: Philippe Ombredanne 
Signed-off-by: Greg Kroah-Hartman 
Acked-by: Felipe Balbi 
Acked-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

usb: optimize acpi companion search for usb port devices

2017-06-03T09:02:58+00:00

This optimization significantly reduces xhci driver load time.

In ACPI tables the acpi companion port devices are children of
the hub device. The port devices are identified by their port number
returned by the ACPI _ADR method.
_ADR 0 is reserved for the root hub device.

The current implementation to find a acpi companion port device
loops through all acpi port devices under that parent hub, evaluating
their _ADR method each time a new port device is added.

for a xHC controller with 25 ports under its roothub it
will end up invoking ACPI bytecode 625 times before all ports
are ready, making it really slow.

The _ADR values are already read and cached earler. So instead of
running the bytecode again we can check the cached _ADR value first,
and then fall back to the old way.

As one of the more significant changes, the xhci load time on
Intel kabylake reduced by 70%, (28ms) from
initcall xhci_pci_init+0x0/0x49 returned 0 after 39537 usecs
to
initcall xhci_pci_init+0x0/0x49 returned 0 after 11270 usecs

Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: find internal hub tier mismatch via acpi

2014-05-27T23:38:52+00:00

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 
Acked-by: Alan Stern 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

usb: cleanup setting udev->removable from port_dev->connect_type

2014-05-27T23:35:10+00:00

Once usb-acpi has set the port's connect type the usb_device's
->removable attribute can be set in the standard location
set_usb_port_removable().

This also changes behavior in the case where the firmware says that the
port connect type is unknown.  In that case just use the default setting
determined from the hub descriptor.

Note, we no longer pass udev->portnum to acpi_find_child_device() in the
root hub case since:
1/ the usb-core sets this to zero
2/ acpi always expects zero
...just pass zero.

Suggested-by: Alan Stern 
Acked-by: Alan Stern 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman