Re: [PATCH 1/2] platform/chrome: cros_ec_typec: Enforce priority-based mode selection

[Shijia Zhang]

Hi Andrei,
I tested both posted patches on a Redrix Chromebook with an HP
Thunderbolt 4 Ultra 180W/280W G6 dock attached throughout boot. My
latest test uses NixOS linux_testing built from upstream Linux v7.2.3.
The Chrome EC reports AP-driven mode entry as enabled:

  /sys/class/chromeos/cros_ec/ap_mode_entry: yes

I am testing this as a user with affected hardware and have limited
familiarity with the kernel's Type-C internals. The observations below
concern patch 1/2; I did not notice a separate problem with patch 2/2.

1. USB4 capability was not exposed

With the posted series alone, cros_ec_typec did not list USB4 in
/sys/class/typec/port1/usb_capability, so the new USB4 entry path was
not reached. The connector has a usb3-port reference. That referenced
USB3 port contains usb4-host-interface and usb4-port-number, while the
connector has no usb4-port reference.

I checked upstream coreboot to understand the firmware topology. At
commit 42f142bd9fad2c9f47c4925845bac6fa686f68c7, the Chrome EC ACPI
generator looks for a USB port object with port type 4 when populating
the connector-level usb4-port reference:

  <https://github.com/coreboot/coreboot/blob/42f142bd9fad2c9f47c4925845bac6fa686f68c7/src/ec/google/chromeec/ec_acpi.c#L46-L90>

The generic connector writer can emit that reference when supplied:

  <https://github.com/coreboot/coreboot/blob/42f142bd9fad2c9f47c4925845bac6fa686f68c7/src/acpi/acpigen_usb.c#L93-L102>

However, I could not find a USB port type 4 object in that tree. The
Intel platform files instead put usb4-host-interface and
usb4-port-number on the xHCI SuperSpeed port. Alder Lake does so here:

  <https://github.com/coreboot/coreboot/blob/42f142bd9fad2c9f47c4925845bac6fa686f68c7/src/soc/intel/alderlake/acpi/tcss_xhci.asl#L120-L186>

I found the same pattern in the Tiger Lake, Meteor Lake, Panther Lake,
and Nova Lake platform files. Linux already consumes this mapping in
usb4_usb3_port_match():

  <https://github.com/torvalds/linux/blob/v7.2/drivers/thunderbolt/usb4_port.c#L95-L127>
  <https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/usb4-acpi-requirements>

To test whether this missing capability was the blocker, I made a
local diagnostic change that kept the connector-level usb4-port check
and also recognized the mapping on the referenced USB3 port. The
Type-C class then reported:

  /sys/class/typec/port1/usb_capability: usb2 usb3 [usb4]

2. USB4 entry did not replace the existing mode

After the diagnostic capability change allowed the posted USB4 path to
run, I observed a second problem. In one cold boot the EC mux initially
reported:

  Port 1: USB=1 DP=1 TBT=0 USB4=0

The cros_typec_enter_usb_mode(..., USB_MODE_USB4) call returned no
error, but the EC remained in the existing mode and no downstream USB4
router appeared. I also observed a boot where the EC reported USB4
while the AP-side mux state was not yet coherent, so treating that
reported USB4 state as a completed transition was not sufficient.

To test whether the existing mode was the blocker, I locally requested
USB_MODE_USB3 to exit modes, waited for a later EC port update to report
DP/TBT/USB4 clear, and then requested USB_MODE_USB4. I advanced those
steps from the existing serialized port worker and used a bounded
timeout only to detect a missing transition.

For this test I also registered the PD notifier before queuing the
initial port update, so a mode-change event generated during that update
could be observed.

With the dock continuously attached, a later cold boot reached:

  EC mux:                                  USB4=1, DP=0, TBT=0
  /sys/class/typec/port1-partner/usb_mode: usb2 usb3 [usb4]
  IOM port status:                         0x86000368

The HP router appeared at 16.885 seconds, its retimer at 17.147
seconds, and boltd authorized a 40 Gb/s link in both directions. The
complete USB hub and 2.5 GbE topology also enumerated, and no
cros_ec_typec transition timeout occurred.

Could you advise whether these observations match the intended behavior?

  1. Is cros_ec_typec expected to obtain USB4 capability from the
     standard mapping on the referenced USB3 port, or is firmware
     expected to provide a connector-level usb4-port reference?
  2. Does the USB4 entry path expect DP/TBT/USB4 to be inactive before
     requesting USB_MODE_USB4? If so, which layer is expected to exit
     the existing mode and wait for completion?

I can provide the exact diagnostic diffs, ACPI topology, kernel
configuration, and full boot logs if useful.

Thanks,
Shijia Zhang