From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: "Ville Kivelä" <vkivela@outlook.com>
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"acelan.kao@canonical.com" <acelan.kao@canonical.com>
Subject: Re: usb: typec: ucsi: duplicate-altmode filter keeps invalid DP partner VDO on Dell XPS 14 DA14260
Date: Mon, 26 Oct 2026 12:38:24 +0100 [thread overview]
Message-ID: <at87sDXF-KHTJAxb@black.igk.intel.com> (raw)
In-Reply-To: <PR3PR10MB3898251C0136EEFE9DEC84FAA5902@PR3PR10MB3898.EURPRD10.PROD.OUTLOOK.COM>
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
next parent reply other threads:[~2026-10-26 11:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <PR3PR10MB3898251C0136EEFE9DEC84FAA5902@PR3PR10MB3898.EURPRD10.PROD.OUTLOOK.COM>
2026-10-26 11:38 ` Heikki Krogerus [this message]
2026-10-26 12:21 ` usb: typec: ucsi: duplicate-altmode filter keeps invalid DP partner VDO on Dell XPS 14 DA14260 Ville Kivelä
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=at87sDXF-KHTJAxb@black.igk.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=acelan.kao@canonical.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=vkivela@outlook.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.