Re: [RFC PATCH] usb: optimize acpi companion search for usb port devices

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 24.05.2017 17:44, Greg KH wrote:
> On Wed, May 24, 2017 at 04:11:12PM +0300, Mathias Nyman wrote:
>> 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, calling
>> 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 <mathias.nyman@linux.intel.com>
>> ---
>>   drivers/usb/core/usb-acpi.c | 26 +++++++++++++++++++++++---
>>   1 file changed, 23 insertions(+), 3 deletions(-)
>
> Why is this RFC?  What's wrong with it as-is?
>

Last minute doubt, nothing should be wrong, but I started to wonder if there is
any particular reason the ACPI part was done the way it was.

Or if maybe other drivers could benefit from checking cached _ADR value first as
well, and this whole thing should be a part of drivers/acpi/glue.c instead?

(adding acpi mailing list, not just Rafael)

Thanks
-Mathias