Re: [PATCH v6 1/3] usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware

["Chia-Lin Kao (AceLan)" <acelan.kao@canonical.com>]

On Wed, Jul 08, 2026 at 01:45:32PM +0200, Greg KH wrote:
> On Fri, Jun 12, 2026 at 01:21:10PM +0800, Chia-Lin Kao (AceLan) wrote:
> > Some firmware implementations incorrectly return the same altmode
> > multiple times at different offsets when queried via
> > UCSI_GET_ALTERNATE_MODES.  This causes sysfs duplicate filename errors
> > and kernel call traces when the driver attempts to register the same
> > altmode twice:
> >
> >   sysfs: cannot create duplicate filename '/devices/.../typec/port0/port0.0/partner'
> >   typec-thunderbolt port0-partner.1: failed to create symlinks
> >   typec-thunderbolt port0-partner.1: probe with driver typec-thunderbolt failed with error -17
> >
> > The matching rules differ by recipient:
> >
> >   - UCSI_RECIPIENT_CON (port) and UCSI_RECIPIENT_SOP_P (plug):
> >     Two altmodes with identical SVID and VDO are byte-for-byte
> >     duplicates and the second has no observable function, so drop it.
> >
> >   - UCSI_RECIPIENT_SOP (partner):
> >     The typec class binds each partner altmode to a port altmode of
> >     the same SVID via altmode_match()/device_find_child(), which
> >     returns the first port altmode with a matching SVID.  If the
> >     partner advertises more altmodes for SVID X than the port
> >     advertises, the surplus partner altmode(s) collapse onto an
> >     already-paired port altmode and trigger the
> >     "duplicate filename .../partner" sysfs error during
> >     typec_altmode_create_links().  Use the port-side altmode count for
> >     SVID X as the authoritative cap and reject any partner altmode
> >     that would exceed it.  This preserves legitimate multi-Mode
> >     partner altmodes (vendor SVIDs that the port really does
> >     advertise more than once) while filtering the firmware-generated
> >     duplicates that have no port counterpart, and is therefore
> >     stricter than a plain SVID+VDO comparison (which still admits the
> >     Thunderbolt case where firmware reports the same SVID twice with
> >     different VDOs) without being over-broad like a plain SVID match
> >     (which would falsely drop legitimate vendor multi-Mode entries).
> >
> > If a duplicate is detected, skip it and emit a clean warning instead
> > of generating a kernel call trace:
> >
> >   ucsi_acpi USBC000:00: con2: Firmware bug: duplicate partner altmode SVID 0x8087 at offset 1, ignoring.
> >   ucsi_acpi USBC000:00: con2: VDO mismatch: 0x8087a043 vs 0x00000001
>
> Can you change the ", ignoring." to ", ignoring but please contact the
> BIOS vendor to fix this issue." as they need to get told this, otherwise
> this looks like it is a kernel issue.
Here is the v7 that just rephrased the warning message.

https://lore.kernel.org/lkml/20260713084323.287516-1-acelan.kao@canonical.com/

>
> thanks,
>
> greg k-h