Re: [PATCH 0/5] usb: typec: ps883x: fixes for older Thunderbolt 4 / USB4 docks

[Sebastian Reichel <sre@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3818 bytes --]

Hi,

On Tue, Jul 21, 2026 at 04:24:06PM +0000, Dr. David Alan Gilbert wrote:
> * Sebastian Reichel (sre@kernel.org) wrote:
> > On Sat, Jul 18, 2026 at 07:06:28PM +0200, Jens Glathe via B4 Relay wrote:
> > > On Qualcomm X1E80100 platforms (e.g. Lenovo ThinkPad T14s Gen 6)
> > > using the Parade PS883x retimer, connecting USB4-capable docks such
> > > as the Lenovo 40B0 via a regular Type-C cable (which forces the dock
> > > into Type-C fallback mode) often results in working USB but no
> > > DisplayPort output.
> > > 
> > > This series addresses the issue with two main changes:
> > > 
> > > - Add a new optional DT property "parade,disable-usb4". When present,
> > >   the PS883x driver rejects USB4 mode (-EOPNOTSUPP). This forces the
> > >   Type-C stack to fall back to USB3 + DP Alt Mode, which works
> > >   reliably with the 40B0.
> > > 
> > > - Refactor DP altmode handling to also support the legacy
> > >   TYPEC_DP_STATE_F request (deprecated since DP Alt Mode 1.0b) sent by
> > >   the 40B0 and other docks (e.g. SSK SC220).
> > > 
> > > - Add a short delay after writing configuration registers, which
> > >   improves hotplug reliability.
> > > 
> > > This is a temporary workaround until full USB4 DP tunneling support is
> > > available in the X1E USB4 controller and qmp-combo PHY stack.
> > > 
> > > Note: The DT patch adds the new property to all currently upstream
> > > boards using the PS883x retimer (15 files). Happy to split it on v2
> > > if requested.
> > 
> > I don't think a kernel driver limitation is a good reason for the DT
> > property. I suggest to add something like this in the ps883x driver
> > instead:
> > 
> > /*
> >  * Hamoa does not yet support USB4, disable it for now to gracefully
> >  * fall back to USB3 + DP AltMode. This should be removed once USB4
> >  * support landed for X1E.
> >  */
> > if (of_machine_is_compatible("qcom,x1e80100"))
> >     disable_usb4 = true;
> 
> It seems a bit of a weird abstraction break to put a machine type
> check down in a device that's not specific to qcom.

It's obviously a hack, but this quirk would be simple and fully
contained within the kernel and thus does not create a new ABI (in
opposite to the DT property). Once the kernel supports USB4 on Hamoa
it could simply be dropped and people have working USB4 with their
existing DT.

> I'd bet it's not just qcom's suffering from this as well.

Qcom boards are the only users of ps883x (the driver is exclusively
probed via DT at the moment). So right now one could also simply
remove any USB4 support from ps883x, but that would work against the
people working on _adding_ proper USB4 support.

IIUIC the problem is, that the Qcom board supports USB4, negotiates
this via the PD protocol and then soft-fails because the software
support is not yet ready. Most other ARM platforms do not have any
USB4/Thunderbolt hardware support to begin with and wouldn't
negotiate it, so they do not run into this in the first place.

AFAIK only Qcom and Apple M series support it. A quick search
suggsts Apple used an Intel retimer in the past and a custom one
nowadays. From the looks of it the x86 world cannot use this driver
either and probably handles retimers transparently in ACPI, so it's
effectively Qcom specific until other vendors start adding USB4
support. The only thing announced potentially running into this
would be the Nvidia RTX Spark, which first needs to be released,
then find a bunch of people motivated to implement upstream support.
Nothing with USB4 capabilities has been announced from Mediatek or
Rockchip. So I wouldn't hold my breath for another user and still
suggested adding the machine check instead of simply disabling USB4
for everyone ;)

Greetings,

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]