Re: usb: typec: ucsi: duplicate-altmode filter keeps invalid DP partner VDO on Dell XPS 14 DA14260

Re: usb: typec: ucsi: duplicate-altmode filter keeps invalid DP partner VDO on Dell XPS 14 DA14260

[Heikki Krogerus]

Hi Ville,

On Sun, Oct 11, 2026 at 07:34:59PM +0000, Ville Kivelä wrote:
> Hi,
> 
> The duplicate partner altmode filter added in 67c92c6419ea ("usb: typec:
> ucsi: Detect and skip duplicate altmodes from buggy firmware") keeps the
> invalid copy of the DisplayPort partner altmode on this machine and drops
> the valid one. The DP altmode driver then cannot bind, and the monitor's
> USB hub never works.

This is why from now on all quirks for this driver are going to be
isolated with either DMI match or something similar.

> Hardware:
>   Dell XPS 14 DA14260 (Intel Panther Lake), BIOS 1.8.2 (2026-05-22)
>   UCSI over ACPI: \_SB_.UBTC (USBC000:00)
>   Partner: Dell U2720Q monitor (DP alt mode + USB hub + PD source)
> Kernel: 7.2.5 (Arch-based distro kernel "7.2.5-3-omarchy")
> 
> The firmware returns the partner's DP altmode (SVID 0xff01) twice on every
> attach:
> 
>   ucsi_acpi USBC000:00: con3: 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: con3: VDO mismatch: 0xff01a043 vs 0x00140045
> 
> The entry at offset 0 is invalid (0xff01a043: SVID in the upper half,
> identical whatever the monitor is configured to). The entry at offset 1
> is the real DP capabilities VDO, and it changes with the monitor's
> "USB-C Prioritization" setting, as expected:
> 
>   High Resolution: 0x00140045 (UFP_D, receptacle, pin assignments C/E)
>   High Data Speed: 0x001c0045 (UFP_D, receptacle, pin assignments C/D/E)
> 
> The port exposes a single DP altmode (port2.1, svid ff01, vdo 0x001c1c46),
> so the per-SVID cap is 1. The filter keeps the first partner entry and
> registers port2-partner.0 with vdo 0xff01a043:
> 
>   $ cat /sys/class/typec/port2-partner/port2-partner.0/{svid,vdo,active}
>   ff01
>   0xff01a043
>   yes
> 
> typec_displayport does not bind to it (no displayport/ directory under the
> partner altmode), so the OS cannot choose a pin assignment.
> 
> Observed result:
>   - High Resolution: video works, but the monitor's hub never enumerates,
>     not even at USB 2.0.
>   - High Data Speed: the hub (0451:8440) enumerates at SuperSpeed on the
>     TCSS xHCI and disconnects within ~1 s, as DP mode is entered. USB 2.0
>     enumeration starts and never completes. There is no video.
> 
>   usb 2-3: new SuperSpeed USB device number 2 using xhci_hcd
>   usb 2-3: New USB device found, idVendor=0451, idProduct=8440, bcdDevice= 1.10
>   hub 2-3:1.0: USB hub found
>   hub 2-3:1.0: 4 ports detected
>   usb 3-4: new high-speed USB device number 6 using xhci_hcd
>   usb 2-3: USB disconnect, device number 2
>   ucsi_acpi USBC000:00: con3: Firmware bug: duplicate partner altmode SVID 0xff01 at offset 1, ignoring ...
>   ucsi_acpi USBC000:00: con3: VDO mismatch: 0xff01a043 vs 0x001c0045
> 
> The same monitor and cable work fully (video and hub) on a MacBook.
> Reproduced on two different USB-C ports, after a full power drain, and
> with Dell's "Video/Power only on Type-C ports" BIOS option disabled.
> 
> The root cause is the firmware, and it has been reported to Dell. However,
> when duplicates disagree, keeping the first entry is arbitrary. Would it
> make sense to prefer an entry that passes basic validation? For SVID 0xff01
> that could mean a non-zero pin assignment field, no reserved bits set, and
> the upper 16 bits not equal to the SVID. Alternatively, the driver could
> prefer the last entry. I'm happy to test patches.

I already send a patch where I disable support for the alternate mode
reporting for all Dell XPS systems, but it looks like Greg missed that
patch - I'll resend it:
https://lore.kernel.org/linux-usb/20260911132850.1580669-1-heikki.krogerus@linux.intel.com/

It does not make sense to attempt to add more and more quirks to this
driver that fix firmware problems on these systems. Dell really has to
fix the PPM.

> Also seen once at boot on the same machine (cleared by reloading ucsi_acpi):
> 
>   ucsi_acpi USBC000:00: con1: failed to register alt modes
>   ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed

That should get fixed with the above patch as well.

Thanks,

-- 
heikki

Re: usb: typec: ucsi: duplicate-altmode filter keeps invalid DP partner VDO on Dell XPS 14 DA14260

[Ville Kivelä]

Hi Heikki,

Thanks for the quick reply, and for resending the patch. Understood that
this needs to be fixed by Dell.

For the DMI match: this machine reports sys_vendor Dell Inc. and
product_name XPS 14 DA14260, so it is covered by the quirk.

Thanks,
Ville


On Mon, Oct 26, 2026 at 1:38 PM Heikki Krogerus
<heikki.krogerus@linux.intel.com> wrote:
>
> Hi Ville,
>
> On Sun, Oct 11, 2026 at 07:34:59PM +0000, Ville Kivelä wrote:
> > Hi,
> >
> > The duplicate partner altmode filter added in 67c92c6419ea ("usb: typec:
> > ucsi: Detect and skip duplicate altmodes from buggy firmware") keeps the
> > invalid copy of the DisplayPort partner altmode on this machine and drops
> > the valid one. The DP altmode driver then cannot bind, and the monitor's
> > USB hub never works.
>
> This is why from now on all quirks for this driver are going to be
> isolated with either DMI match or something similar.
>
> > Hardware:
> >   Dell XPS 14 DA14260 (Intel Panther Lake), BIOS 1.8.2 (2026-05-22)
> >   UCSI over ACPI: \_SB_.UBTC (USBC000:00)
> >   Partner: Dell U2720Q monitor (DP alt mode + USB hub + PD source)
> > Kernel: 7.2.5 (Arch-based distro kernel "7.2.5-3-omarchy")
> >
> > The firmware returns the partner's DP altmode (SVID 0xff01) twice on every
> > attach:
> >
> >   ucsi_acpi USBC000:00: con3: 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: con3: VDO mismatch: 0xff01a043 vs 0x00140045
> >
> > The entry at offset 0 is invalid (0xff01a043: SVID in the upper half,
> > identical whatever the monitor is configured to). The entry at offset 1
> > is the real DP capabilities VDO, and it changes with the monitor's
> > "USB-C Prioritization" setting, as expected:
> >
> >   High Resolution: 0x00140045 (UFP_D, receptacle, pin assignments C/E)
> >   High Data Speed: 0x001c0045 (UFP_D, receptacle, pin assignments C/D/E)
> >
> > The port exposes a single DP altmode (port2.1, svid ff01, vdo 0x001c1c46),
> > so the per-SVID cap is 1. The filter keeps the first partner entry and
> > registers port2-partner.0 with vdo 0xff01a043:
> >
> >   $ cat /sys/class/typec/port2-partner/port2-partner.0/{svid,vdo,active}
> >   ff01
> >   0xff01a043
> >   yes
> >
> > typec_displayport does not bind to it (no displayport/ directory under the
> > partner altmode), so the OS cannot choose a pin assignment.
> >
> > Observed result:
> >   - High Resolution: video works, but the monitor's hub never enumerates,
> >     not even at USB 2.0.
> >   - High Data Speed: the hub (0451:8440) enumerates at SuperSpeed on the
> >     TCSS xHCI and disconnects within ~1 s, as DP mode is entered. USB 2.0
> >     enumeration starts and never completes. There is no video.
> >
> >   usb 2-3: new SuperSpeed USB device number 2 using xhci_hcd
> >   usb 2-3: New USB device found, idVendor=0451, idProduct=8440, bcdDevice= 1.10
> >   hub 2-3:1.0: USB hub found
> >   hub 2-3:1.0: 4 ports detected
> >   usb 3-4: new high-speed USB device number 6 using xhci_hcd
> >   usb 2-3: USB disconnect, device number 2
> >   ucsi_acpi USBC000:00: con3: Firmware bug: duplicate partner altmode SVID 0xff01 at offset 1, ignoring ...
> >   ucsi_acpi USBC000:00: con3: VDO mismatch: 0xff01a043 vs 0x001c0045
> >
> > The same monitor and cable work fully (video and hub) on a MacBook.
> > Reproduced on two different USB-C ports, after a full power drain, and
> > with Dell's "Video/Power only on Type-C ports" BIOS option disabled.
> >
> > The root cause is the firmware, and it has been reported to Dell. However,
> > when duplicates disagree, keeping the first entry is arbitrary. Would it
> > make sense to prefer an entry that passes basic validation? For SVID 0xff01
> > that could mean a non-zero pin assignment field, no reserved bits set, and
> > the upper 16 bits not equal to the SVID. Alternatively, the driver could
> > prefer the last entry. I'm happy to test patches.
>
> I already send a patch where I disable support for the alternate mode
> reporting for all Dell XPS systems, but it looks like Greg missed that
> patch - I'll resend it:
> https://lore.kernel.org/linux-usb/20260911132850.1580669-1-heikki.krogerus@linux.intel.com/
>
> It does not make sense to attempt to add more and more quirks to this
> driver that fix firmware problems on these systems. Dell really has to
> fix the PPM.
>
> > Also seen once at boot on the same machine (cleared by reloading ucsi_acpi):
> >
> >   ucsi_acpi USBC000:00: con1: failed to register alt modes
> >   ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed
>
> That should get fixed with the above patch as well.
>
> Thanks,
>
> --
> heikki