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

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

On Sat, Sep 12, 2026 at 02:43:14PM +0200, Manuel Knitza wrote:
> Thanks Heikki, and thanks for looping in Dell.
> 
> Tested on both kernels. Short version: the DMI match is right, the quirk
> does exactly what it is meant to do, nothing regresses -
> 
> Tested-by: Manuel Knitza <manuel.knitza@googlemail.com>
> 
> - but it does not fix the loss of function, and I think that part is
> what needs to reach Dell.

Thanks. Let's hope the guys from Dell take a look at this.

Br,

> DMI match
> ---------
> 
> Confirmed here:
> 
>     DMI_SYS_VENDOR   = "Dell Inc."
>     DMI_PRODUCT_NAME = "XPS 16 DA16260"
> 
> Both DMI_MATCH substrings hit, so the quirk applies.
> 
> Build note
> ----------
> 
> The patch does not build on 7.1.x: there ucsi_sync_control_common() and
> the .sync_control callback still take 5 arguments; msg_out/msg_out_size
> arrived in 7.2. Against 7.2.x it compiles clean, no warnings. Mentioning
> it only so nobody wastes time trying it on an older stable kernel.
> 
> Test result, unmodified patch on 7.2.3-arch1-3
> ----------------------------------------------
> 
> Before, with the stock module:
> 
>     Alt modes registered: 1
>     port1-partner.0  svid=8087  vdo=0x8087a043  active=no
>     ucsi_acpi USBC000:00: con2: Firmware bug: duplicate partner
> altmode SVID 0x8087 ...
>     ucsi_acpi USBC000:00: con2: VDO mismatch: 0x8087a043 vs 0x00000001
> 
> After loading the patched module:
> 
>     ucsi_acpi USBC000:00: Firmware bug: broken altmode details
> reporting, disabling
>     Alt modes registered: 0
>     duplicate-altmode messages: 0
>     all three connectors register normally
> 
> The already running DisplayPort link was not disturbed by the module
> swap at any point: 5120x2160@60, port_clock 810000, lane_count 4, bpp 24
> throughout. I also ran the same change backported to the 5-argument
> signature on 7.1.8, with the same result.
> 
> One practical note for anyone repeating this: swap the module with
> "rmmod ucsi_acpi", not "modprobe -r" - the latter also drops the then
> unused typec_ucsi, and the new module fails with "Unknown symbol
> ucsi_create".
> 
> What it does not fix
> --------------------
> 
> With the unmodified patch loaded on 7.2.3 I unplugged and re-plugged the
> monitor. The USB side comes back completely - hub, HID, cdc_acm all
> re-enumerate - and DP-1 stays "disconnected". Zero UCSI messages this
> time. Same outcome with the backport on 7.1.8. So not querying the alt
> mode details does not change the functional result.
> 
> That matches an accidental experiment from a few days earlier: setting
> ThunderboltPorts=Disabled in the BIOS stops the firmware offering the
> Thunderbolt SVID, after which the kernel registers no partner alt modes
> at all - and DisplayPort still works perfectly when the cable is attached
> at boot, and still fails on hotplug.
> 
> Which means I should correct my own original report: I claimed the
> retained malformed VDO caused the failure. It does not. While a 4-lane
> HBR3 link was running I read
> 
>     port2-partner.0  vdo=0xff01a843 (the malformed one)  active=yes
>     displayport/     configuration=[USB]  pin_assignment=A  hpd=0
> 
> On this platform the typec alt mode bookkeeping never described reality
> in the first place. Your patch removes data that was actively
> misleading, which is worth doing on its own - but the bug underneath is
> elsewhere.
> 
> The remaining bug, for Dell
> ---------------------------
> 
> DP Alt Mode is never entered again once the machine is running:
> 
>     cold boot with cable attached   always works
>     hotplug                         never works
>     resume from s2idle              never works
>     hibernate (S4)                  always works   <- full POST
> 
> It is not limited to suspend. Merely blanking the screen is enough. The
> lock screen issues a DPMS off on all outputs, the monitor deep-sleeps,
> drops the link, and it never returns:
> 
>     xe [drm] *ERROR* [CONNECTOR:521:DP-1] Invalid DPCD with no link rates
>     xe [drm] *ERROR* [CONNECTOR:521:DP-1] Invalid DPCD max lane count (0)
> 
> with the machine awake throughout - no PM: suspend entry in the log,
> uptime continuous. The USB-C connection never drops; only the DP link
> inside it dies.
> 
> Nothing on the OS side brings it back. Tried and failed, all of them:
> 
>   - power-cycling the monitor
>   - modprobe -r ucsi_acpi && modprobe ucsi_acpi, in both orders relative
>     to re-plugging the cable
>   - echo 1 > /sys/kernel/debug/dri/0/DP-1/i915_dp_force_link_retrain
>   - echo detect / echo on > /sys/class/drm/card0-DP-1/status
>     ("on" yields only VESA fallback modes, no EDID - AUX does not answer)
>   - echo device > /sys/class/typec/port1/data_role  -> EACCES
>   - echo source > /sys/class/typec/port1/power_role -> EIO, plus
>     "ucsi_acpi: unknown error 0"
> 
> A reboot is the only way back, which is hard to live with on a docked
> laptop. My workaround is a small service that re-enables DPMS on external
> outputs whenever anything turns them off, so the link is never dropped in
> the first place.
> 
> Hardware: Dell XPS 16 DA16260, BIOS 1.10.1. Identical behaviour with a
> plain USB-C-to-DP adapter and with a direct USB-C cable to the monitor,
> so it is not the adapter.
> 
> Happy to test patches or firmware and to collect any traces that help -
> the machine reproduces all of this on demand.
> 
> Am Fr., 11. Sept. 2026 um 12:15 Uhr schrieb 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

-- 
heikki