https://bugzilla.kernel.org/show_bug.cgi?id=221987

McKenna_Fan ([email protected]) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Config-Tables               |USB
            Product|ACPI                        |Drivers

--- Comment #2 from McKenna_Fan ([email protected]) ---
Retested on 7.3.0-1-MANJARO: the boot warning and peer-mapping pattern remain
present.

Hardware is unchanged:
- ASUS TUF GAMING B550-PRO
- BIOS 3644, dated 2026-08-19
- Controller 0000:02:00.0, PCI ID 1022:43ee, subsystem 1b21:1142
- Driver: xhci_hcd
- ACPI path: \_SB_.PCI0.GPP1.PTXH

Current sysfs state:

    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  not used  location=0x8000000b  peer=NONE

Ports 3 and 4 retain reciprocal USB2/SuperSpeed peer mappings.

The current boot log shows:

    [9.564455] usb usb2: SerialNumber: 0000:02:00.0
    [9.564586] hub 2-0:1.0: USB hub found
    [9.564716] hub 2-0:1.0: 4 ports detected
    [9.564724] usb: port power management may be unreliable

This was tested on a distribution kernel. /proc/sys/kernel/tainted reported
12288 at collection time.

I am moving the report to Drivers / USB to reflect comment 1, which supersedes
my original firmware-typo diagnosis. My suggestion to change PT2[1] from 0x0a
to 0x0b is withdrawn.

The question remains whether USB core’s one-to-one peer representation can
handle this apparent one-USB2-to-two-SuperSpeed Type-C topology. The observed
state is consistent with the peer-link collision and port-power-off fallback
discussed in comment 1; this retest did not directly instrument link_peers() or
read usb_port_block_power_off.

Could a USB maintainer review whether this topology requires different peer
handling? No causal connection to the separately mentioned S3 resume failure is
claimed.

AI assistance was used in the investigation, source analysis, and drafting. The
runtime output and firmware excerpts were collected from my machine.

-- 
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

Reply via email to