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

[Andrei Kuchynski]

On Fri, Sep 4, 2026 at 1:50 PM Shijia Zhang <codgician@xxxxxxxxxxx> wrote:
>
> 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?

Hi Shijia,

Thanks for running tests on the patch!

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

I am unable to assist with this directly. A potential workaround would be
altering the cros_typec_parse_port_props function:

    //if (fwnode_property_present(fwnode, "usb4-port"))
        cap->usb_capability |= USB_CAPABILITY_USB4;

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

No, it doesn’t. The typecd daemon probably enables DP altmode.
To test mode_selection, stop the service first:

# stop typecd

Thanks,
Andrei