Re: [PATCH] usb: typec: altmode: Fix altmode to handle multiple parners

[Heikki Krogerus <heikki.krogerus@linux.intel.com>]

Hi François,

Thank you for the info.

On Thu, Apr 02, 2026 at 08:10:09PM +0200, François Scala wrote:
> Hi,
> 
> On 02/04/2026 15.26, Heikki Krogerus wrote:
> > No. You can not have more than a single partner per mode. Let's figure
> > out the root issue. Please check the svids of the partner altmodes:
> > 
> >          grep . /sys/class/typec/port0-partner/port0-partner.*/svid
> 
> /sys/class/typec/port2-partner/port2-partner.0/svid:8087
> /sys/class/typec/port2-partner/port2-partner.1/svid:8087

Okay, the other svid should almost certainly be ff01 (the DisplayPort
Alternate Mode), most likely the second one (port2-partner.1). 8087 is
the Thunderbolt Alternate Mode, and it should now be always companied
by the DisplayPort Alternate Mode.

>      kworker/5:2-321     [005] .....   465.001617: ucsi_connector_change:
> port3 status: change=4000, opmode=4, connected=1, sourcing=1,
> partner_flags=1, partner_type=2, request_data_obj=00000000, BC status=1
>      kworker/5:2-321     [005] .....   465.111779: ucsi_connector_change:
> port3 status: change=0060, opmode=3, connected=1, sourcing=1,
> partner_flags=1, partner_type=2, request_data_obj=13800000, BC status=1
>      kworker/8:1-174     [008] .....   465.429999: ucsi_connector_change:
> port3 status: change=1000, opmode=5, connected=1, sourcing=0,
> partner_flags=1, partner_type=2, request_data_obj=13800000, BC status=1
>      kworker/8:1-174     [008] .....   465.532708: ucsi_connector_change:
> port3 status: change=0060, opmode=3, connected=1, sourcing=0,
> partner_flags=1, partner_type=2, request_data_obj=42c4b12c, BC status=1
>     kworker/10:1-178     [010] .....   465.883679: ucsi_connector_change:
> port3 status: change=0060, opmode=3, connected=1, sourcing=0,
> partner_flags=1, partner_type=2, request_data_obj=42c7a9ea, BC status=1
>      kworker/3:0-13120   [003] .....   466.330330: ucsi_connector_change:
> port3 status: change=0060, opmode=3, connected=1, sourcing=0,
> partner_flags=1, partner_type=2, request_data_obj=82c7d1f4, BC status=1
>    kworker/u64:2-356     [005] .....   466.890372: ucsi_register_altmode:
> partner alt mode: svid 8087, mode 1 vdo 8087a843

Here the vdo seems to be corrupted in the response to the
GET_ALTERNATE_MODES command.

As you can see, the first 16-bits in the vdo is clearly the TBT svid
again even though the vdo should contain the actual Vendor Defined Object
for the TBT alt mode.

>    kworker/u64:2-356     [005] .....   467.005141: ucsi_register_altmode:
> partner alt mode: svid 8087, mode 2 vdo 1

And here the firmware is returning the TBT SVID again for the second
time, now with vdo that looks almost valid to me. This should not
happen.

The responses to the GET_ALTERNATE_MODES look similar to what we see
on some of the Dell laptops. The response seems almost as if it's
customised some how. It's almost as if the first run of the command
will return some kind of a list of the SVIDs, and the standard
responses start only after the second run of the command.

> > For acpidump you need the acpica-tools installed:
> > 
> >          acpidump -o my_acpi.dump
> 
> The file is quite large, how can I share it ? Or do you need a specific part
> ?
> 
>   -rw-r--r-- 1 fs fs 4.7M Apr  2 19:05 acpi-port3-20260402.dump

It does not look that big. Compress and send to me (drop the list if
you prefer)?

I still have no idea which system are you running? Can you send the
dmesg output from freshly booted machine?

thanks,

-- 
heikki