Bug 218465

Created attachment 305840 [details]
Output of `acpidump` with system firmware 1.21.0

High-speed (HS) ans SuperSpeed (SS) ports are peered based on their Physical Location Description (_PLD) object in ACPI tables.

The SSDT7 ACPI table dump shows that _PLD is created by calling a GPLD
helper method with some parameters. For High-Speed ports (HS0x) this seems
to be called with increasing port numer up to HS port 5. From port 6 onwards
all parameters are 0.

Scope (\_SB.PCI0.XHC.RHUB.HS01)
    Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
        Return (GPLD (One, One))

Scope (\_SB.PCI0.XHC.RHUB.HS02)
    Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
        Return (GPLD (One, 0x02))
...
Scope (\_SB.PCI0.XHC.RHUB.HS05)
    Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
        Return (GPLD (Zero, 0x05))

Scope (\_SB.PCI0.XHC.RHUB.HS06)
    Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
        Return (GPLD (Zero, Zero))

Scope (\_SB.PCI0.XHC.RHUB.HS07)
    Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
        Return (GPLD (Zero, Zero))

For SuperSpeed ports (SS0x) the same is true. Ports 1-

Scope (\_SB.PCI0.XHC.RHUB.SS01)
    Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
        Return (GPLD (One, One))

Scope (\_SB.PCI0.XHC.RHUB.SS02)
    Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
        Return (GPLD (One, 0x02))

Scope (\_SB.PCI0.XHC.RHUB.SS03)
    Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
        Return (GPLD (Zero, Zero))

Scope (\_SB.PCI0.XHC.RHUB.SS04)
    Method (_UPC, 0, NotSerialized)  // _UPC: USB Port Capabilities
        Return (GPLD (Zero, Zero))

Basically all HS port from 6 upwards and SS ports from 3 upwards report the
same _PLD, this messes up port peering and results in the following messages during boot:  

usb usb2-port1: peered to usb1-port1
usb usb2-port2: peered to usb1-port2
usb usb2-port3: peered to usb1-port6
usb: failed to peer usb2-port4 and usb1-port6 by location (usb2-port4:none) (usb1-port6:usb2-port3)
usb usb2-port4: failed to peer to usb1-port6 (-16)
usb: port power management may be unreliable
usb: failed to peer usb2-port5 and usb1-port6 by location (usb2-port5:none) (usb1-port6:usb2-port3)
usb usb2-port5: failed to peer to usb1-port6 (-16)
usb: failed to peer usb2-port6 and usb1-port6 by location (usb2-port6:none) (usb1-port6:usb2-port3)
usb usb2-port6: failed to peer to usb1-port6 (-16)

Thank you for the analysis. Excuse my ignorance, but does this mean it’s a firmware issue, or Linux’ assumptions are incorrect?

*** This bug has been marked as a duplicate of bug 218490 ***

This DELL machine has ACPI entries for USB ports that are not usable.
These ports are supported by xHCI host hardware but are not internally or externally connected anywhere.  They have _UPC (USB port capability) ACPI objects stating they are not connectable, and _PLD (Physical Location of Device) that just returns 0 for their group token group position.

So all unusable USB2 and USB3 ports have similar _PLD entries, which then confuses Linux when trying to pair together USB2 and USB3 ports. 

Linux could probably ignore printing any warning messages for ports that
have _PLD entries but _UPC shows they are not connectable