Hi,

On Wed, Jul 22, 2026 at 10:38:34AM +0200, Jens Glathe wrote:
> On 7/22/26 01:34, Sebastian Reichel wrote:
> > On Tue, Jul 21, 2026 at 04:24:06PM +0000, Dr. David Alan Gilbert wrote:
> > > * Sebastian Reichel (sre@kernel.org) 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:

That's exactly what this series is doing and not really a problem
considering USB4 is not working anyways.

> - 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.

DT is not a kernel config file. You can find that in .config. The DT
describes the hardware. Writing in DT "no-usb4" means that the
hardware does not support USB4. But the board files you are changing
can do USB4 in hardware. Thus the DT entry is wrong.

> 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 understand that part. That's why I suggested to just put the
disable_usb4 = true; in there without the DT check instead of
something completley differnt. That's exactly the same, except
that the information is fully contained within the kernel.

This is actually __less__ intrusive:

 - less code
 - there is no need to touch all board files
 - the hardware description stays correct
 - it does not create ABI (you are supposed to continue supporting
   the new flag also after known users dropped it)
 - affects the same devices (all X1E)
 - but automatically also affects newly added boards
 - it's easier to revert (no need to touch all board files)

If you don't want to have a hack, the proper fix would be to detect
that the follow-up stack is not capable of handlin USB4 and avoid
exposing it. I'm aware that this is a quite complex task and
considering USB4 is WIP anyways, I would go with the hack until
then.

> 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.

I'm not doubting the result of the patch series and plan to test
with my TB capable Dell U2725QE later.

Greetings,

-- Sebastian