Re: [BUG] ucsi: duplicate partner altmode — the invalid VDO wins, DP Alt Mode never works

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

+Dell and Guilhem

On Wed, Sep 09, 2026 at 03:25:11PM +0200, Manuel Knitza wrote:
> Hi,
> 
> on a Dell XPS 16 DA16260 (Panther Lake, BIOS 1.10.1) the UCSI firmware
> reports the
> DisplayPort alternate mode twice with conflicting VDOs. The kernel
> keeps the first entry
> and discards the second — but here the first is the malformed one, and
> the result is that
> DisplayPort Alt Mode never works on any port when a plain USB-C→DP
> adapter is hotplugged.
> 
> >     ucsi_acpi USBC000:00: con2: Firmware bug: duplicate partner altmode SVID 0xff01 at
> >         offset 1, ignoring but please contact the BIOS vendor to fix this issue.
> >     ucsi_acpi USBC000:00: con2: VDO mismatch: 0xff01a843 vs 0x40101407
> 
> 
> Identical output on con3. Reproduced on 7.1.8 and 7.2.3.
> 
> The firmware is clearly at fault and the message says so. My point is
> a different one: of
> the two VDOs the firmware offers, one is usable and the kernel
> systematically picks the
> other, turning a firmware quirk into a total loss of function.
> 
> > Retained  0xff01a843 — top 16 bits are 0xff01, i.e. the SVID itself, apparently packed
> >                        into the VDO field by the firmware. Parsed as a DP VDO this
> >                        advertises only pin assignments D and F (2 lanes).
> > Discarded 0x40101407 — well-formed DP Alt Mode VDO: DFP_D + UFP_D, DPv1.3 signalling,
> >                        UFP_D pin assignments C and E (4 lanes).
> 
> 
> The adapter itself is not the source of the duplicate. Its USB
> Billboard descriptor
> declares exactly one alternate mode:
> 
> >     Billboard capability: supported alt modes = 1, preferred = 0
> >       [0] SVID = 0xff01
> >     Billboard AltMode capability: dwAltModeVdo = 0x40101007
> 
> 
> So the device offers a single, valid DP VDO; the duplication and the
> corrupted variant are
> produced on the UCSI/PPM side.
> 
> Consequences with the malformed VDO retained:
> 
>   - /sys/class/typec/portX-partner/portX-partner.0/displayport/pin_assignment
> shows "D F",
>     never C or E, so even a working link could not carry 4 lanes.
>   - hpd stays 0; the sink is never seen.
>   - Writing to .../displayport/pin_assignment fails with
>       typec_displayport portX-partner.0: firmware doesn't support
> alternate mode overriding
>     so userspace cannot correct it either.
> 
> Interestingly the hardware path is fine: if the same adapter is
> already connected at boot,
> the display comes up at full 5120x2160@60, port_clock 810000 (HBR3),
> lane_count 4, bpp 24.
> Only the hotplug path, which goes through UCSI, fails. That reinforces
> that the platform
> can do 4-lane DP and only the altmode bookkeeping is wrong.
> 
> Would it be reasonable for ucsi_altmode_is_duplicate() /
> ucsi_register_altmode() to prefer
> a VDO that parses as valid for the given SVID over one that does not,
> instead of keeping
> whichever arrived first? For DP Alt Mode a cheap sanity check exists —
> a VDO whose upper
> bits repeat the SVID, or which advertises no pin assignment usable by
> the port, is not a
> plausible descriptor. Keeping the current warning would still tell the
> user their firmware
> is broken, while not letting it break the port.
> 
> I am happy to test patches; the machine reproduces this on every hotplug.
> 
> Relevant symbols in the module: ucsi_altmode_is_duplicate,
> ucsi_register_altmode,
> ucsi_register_altmodes, ucsi_check_altmodes, ucsi_dump_duplicate_altmode.
> 
> Full message text for reference:
>     "con%d: Firmware bug: duplicate %s altmode SVID 0x%04x at offset
> %d, ignoring but
>      please contact the BIOS vendor to fix this issue."
>     "con%d: VDO mismatch: 0x%08x vs 0x%08x"
> 
> --
> 
> A second, probably unrelated observation on the same machine,
> mentioned only in case it
> rings a bell: ucsi_acpi frequently fails at boot with
> 
>     ucsi_acpi USBC000:00: con1: failed to register alt modes
>     ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed
> 
> after which /sys/class/typec/ is empty for the rest of the session.
> Reloading the module
> ("modprobe -r ucsi_acpi && modprobe ucsi_acpi") brings all three ports
> up. UCSI_GET_PDOS
> also fails persistently with -5 and occasionally -95. Same firmware,
> same platform. I can
> send that as a separate report with full logs if it is of interest.

Thanks for the report. There are now a lot of issues with the altmodes
on these Dell XPS laptops. These problems have been reported also on
earlier Dell XPS 13 and on some other Dell systems too.

Hopefully Dell fixes their EC/PPM firmware at some point, but for now,
I'm removing the alternate mode details UCSI feature flag from all
Dell XPS systems. That means the alternate modes are not going to be
registered at all on these laptops.

thanks,

-- 
heikki