https://bugzilla.kernel.org/show_bug.cgi?id=221987
--- Comment #1 from McKenna_Fan ([email protected]) --- I need to correct an important part of my original diagnosis. Further analysis indicates that the duplicate _PLD group position on this ASUS board is very likely intentional and valid for the USB-C topology, rather than a firmware typo. The affected controller has the following live sysfs topology: usb1-port1 hotplug location=0x8000000a peer=usb2-port1 usb2-port1 hotplug location=0x8000000a peer=usb1-port1 usb2-port2 hotplug location=0x8000000a peer=NONE usb1-port2, which has the next location value 0x8000000b, is explicitly not used. In the DSDT, the relevant ports use _UPC connector type 0x0A. ACPI defines this as a USB Type-C connector providing USB2 and SuperSpeed without a switch. In such a topology, the two SuperSpeed signal paths can be represented by separate host-controller ports while referring to the same physical Type-C receptacle, so multiple logical USB ports legitimately share the same _PLD. Cross-vendor DSDT comparison supports this interpretation. Gigabyte and ASRock X570 firmware also contain connectable _UPC type 0x0A ports where multiple SuperSpeed logical ports share one _PLD location. This argues against the duplicate location being an ASUS-specific firmware error. The Linux USB core appears unable to represent this topology fully. In v7.2: struct usb_port { ... struct usb_port *peer; ... }; usb_acpi_get_connect_type() evaluates _UPC, but uses only element 0 to determine whether the port is connectable; I found no use of _UPC element 1, which contains the connector type. Location-based peer matching then calls link_peers(). That function supports only a one-to-one relationship and returns -EBUSY when either port already has a peer: if (left->peer || right->peer) return -EBUSY; That error is handled by: pr_warn_once("usb: port power management may be unreliable\n"); usb_port_block_power_off = 1; The observed runtime state is consistent with this exact path: the USB2 port at location 0x0a is successfully peered with the first SuperSpeed port at the same location, while the second SuperSpeed port at that same valid physical location remains unpeered. There is also a newer Type-C port-mapping layer which explicitly aggregates ACPI devices sharing a Type-C connector's _PLD, so Linux appears to have two different models here: the Type-C connector layer can associate multiple USB ports with one physical connector, while the older USB port power-management peer model remains one-to-one. Historical review also suggests the one-peer model predates USB Type-C. The original 2013 USB port-power RFC considered a more general connector object containing multiple ports, but the implementation was simplified to a single peer relationship on the assumption that a port would not need more than one peer. The resulting peer model landed in 2014, before USB Type-C 1.0 was finalized. Physical port mapping on this system is also consistent with the ACPI description. The controller exposes four SuperSpeed root ports. The two accessible front-panel USB3 Type-A ports enumerate as Bus 2 ports 3 and 4, leaving Bus 2 ports 1 and 2 — the two ports sharing location 0x0a — consistent with the board's separate front-panel Type-C connection. Therefore my current interpretation is: The firmware is likely describing a valid USB-C no-switch topology, while the Linux USB core's one-to-one peer representation cannot model the one-USB2-to-two-SuperSpeed relationship. The failed second peer link then produces the generic "port power management may be unreliable" warning and globally blocks USB port power-off. I withdraw my earlier suggestion that the PT2[1] value should be changed from 0x0a to 0x0b. The separate S3 resume message from this controller: xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit remains a separate observation. I still have no evidence that it is caused by the peer-mapping issue described above. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
