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

[Jens Glathe]

Hi,

On 7/22/26 01:34, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Jul 21, 2026 at 04:24:06PM +0000, Dr. David Alan Gilbert wrote:
> > * Sebastian Reichel (sre@xxxxxxxxxx) wrote:
> > > 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
I understand, however I wouldn't want to nerf ps883x for the Hamoa 
platform until the USB4 stack is complete. The issues you currently run 
into is:

- you use a tbt4 / usb4 cable and nothing works,

- you have a tbt4 / usb4 capable device in fallback mode that does 
complex stuff when negotiating and firmware / a partial USB4 stack 
requests USB4, which ends up not working.

Both cases are not the hardware's fault, it is capable of USB4. The 
driver stack isn't. Therefore I would prefer to deliberately disable 
USB4 modes by device via the DT. That way it can fall back to 
re-negotiating something the driver stack is capable of. PS883x is not 
the place where this starts, but where it's convenient to stop.

I did some tests without USB4 disabled and the 40B0 stack in type-c 
cable fallback mode, and most of the time it just works. Except for an 
unlucky plug, and despite it shouldn't request USB4, the request lands 
at the redriver. Disabling USB4 modes reliably let's it renegotiate.

with best regards

Jens