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

From: Chia-Lin Kao (AceLan)

Date: Mon Jul 13 2026 - 04:51:06 EST


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@xxxxxxxxxxxxx/

>
> thanks,
>
> greg k-h