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.

As an additional observation, the same dock with type-c cable works well
on Thinkpad X13s, Thinkbook 16 G7 QOY, Ideapad 5 14Q8X9, but doesn't need
the ps883x changes (naturally). 

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
---
Jens Glathe (5):
      dt-bindings: usb: parade,ps8830: Add parade,disable-usb4 property
      usb: typec: ps883x: Return -EOPNOTSUPP for USB4 when parade,disable-usb4 is set
      usb: typec: mux: ps883x: refactor DP altmode handling and support TYPEC_DP_STATE_F
      usb: typec: mux: ps883x: add a delay after writing config regs
      arm64: dts: qcom: x1: disable ps883x USB4 capability

 .../devicetree/bindings/usb/parade,ps8830.yaml     |  6 +++
 arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts         |  4 ++
 .../qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts  |  2 +
 arch/arm64/boot/dts/qcom/purwa-iot-evk.dts         |  6 +++
 arch/arm64/boot/dts/qcom/x1-asus-vivobook-s15.dtsi |  4 ++
 arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi  |  4 ++
 arch/arm64/boot/dts/qcom/x1-crd.dtsi               |  6 +++
 arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi        |  4 ++
 arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi   |  2 +
 arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi  |  4 ++
 arch/arm64/boot/dts/qcom/x1e001de-devkit.dts       |  6 +++
 .../dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi    |  4 ++
 .../boot/dts/qcom/x1e80100-dell-xps13-9345.dts     |  4 ++
 .../boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts  |  6 +++
 .../dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts    |  2 +
 .../boot/dts/qcom/x1e80100-microsoft-romulus.dtsi  |  4 ++
 drivers/usb/typec/mux/ps883x.c                     | 47 +++++++++++++++-------
 17 files changed, 100 insertions(+), 15 deletions(-)
---
base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f
change-id: 20260718-ps883x-disable-usb4-19b0fc13b5ab

Best regards,
-- 
Jens Glathe <jens.glathe@oldschoolsolutions.biz>

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.

Just for my understanding, here you mean a Type-C cable with all 4 lanes
and the SBU lines?

> 
> 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.
> 
> As an additional observation, the same dock with type-c cable works well
> on Thinkpad X13s, Thinkbook 16 G7 QOY, Ideapad 5 14Q8X9, but doesn't need
> the ps883x changes (naturally). 
> 
> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
> ---
> Jens Glathe (5):
>       dt-bindings: usb: parade,ps8830: Add parade,disable-usb4 property
>       usb: typec: ps883x: Return -EOPNOTSUPP for USB4 when parade,disable-usb4 is set
>       usb: typec: mux: ps883x: refactor DP altmode handling and support TYPEC_DP_STATE_F
>       usb: typec: mux: ps883x: add a delay after writing config regs
>       arm64: dts: qcom: x1: disable ps883x USB4 capability
> 
>  .../devicetree/bindings/usb/parade,ps8830.yaml     |  6 +++
>  arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts         |  4 ++
>  .../qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts  |  2 +
>  arch/arm64/boot/dts/qcom/purwa-iot-evk.dts         |  6 +++
>  arch/arm64/boot/dts/qcom/x1-asus-vivobook-s15.dtsi |  4 ++
>  arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi  |  4 ++
>  arch/arm64/boot/dts/qcom/x1-crd.dtsi               |  6 +++
>  arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi        |  4 ++
>  arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi   |  2 +
>  arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi  |  4 ++
>  arch/arm64/boot/dts/qcom/x1e001de-devkit.dts       |  6 +++
>  .../dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi    |  4 ++
>  .../boot/dts/qcom/x1e80100-dell-xps13-9345.dts     |  4 ++
>  .../boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts  |  6 +++
>  .../dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts    |  2 +
>  .../boot/dts/qcom/x1e80100-microsoft-romulus.dtsi  |  4 ++
>  drivers/usb/typec/mux/ps883x.c                     | 47 +++++++++++++++-------
>  17 files changed, 100 insertions(+), 15 deletions(-)
> ---
> base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f
> change-id: 20260718-ps883x-disable-usb4-19b0fc13b5ab
> 
> Best regards,
> -- 
> Jens Glathe <jens.glathe@oldschoolsolutions.biz>
> 
> 

-- 
With best wishes
Dmitry

Hi,

On 7/21/26 19:56, Dmitry Baryshkov wrote:
> Just for my understanding, here you mean a Type-C cable with all 4 lanes
> and the SBU lines?

Yes. I used the type-c cables from my portable USB-C display, which does 
4k@60.

with best regards

Jens

Hello,

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;

Greetings,

-- Sebastian

> As an additional observation, the same dock with type-c cable works well
> on Thinkpad X13s, Thinkbook 16 G7 QOY, Ideapad 5 14Q8X9, but doesn't need
> the ps883x changes (naturally). 
> 
> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
> ---
> Jens Glathe (5):
>       dt-bindings: usb: parade,ps8830: Add parade,disable-usb4 property
>       usb: typec: ps883x: Return -EOPNOTSUPP for USB4 when parade,disable-usb4 is set
>       usb: typec: mux: ps883x: refactor DP altmode handling and support TYPEC_DP_STATE_F
>       usb: typec: mux: ps883x: add a delay after writing config regs
>       arm64: dts: qcom: x1: disable ps883x USB4 capability
> 
>  .../devicetree/bindings/usb/parade,ps8830.yaml     |  6 +++
>  arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts         |  4 ++
>  .../qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts  |  2 +
>  arch/arm64/boot/dts/qcom/purwa-iot-evk.dts         |  6 +++
>  arch/arm64/boot/dts/qcom/x1-asus-vivobook-s15.dtsi |  4 ++
>  arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi  |  4 ++
>  arch/arm64/boot/dts/qcom/x1-crd.dtsi               |  6 +++
>  arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi        |  4 ++
>  arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi   |  2 +
>  arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi  |  4 ++
>  arch/arm64/boot/dts/qcom/x1e001de-devkit.dts       |  6 +++
>  .../dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi    |  4 ++
>  .../boot/dts/qcom/x1e80100-dell-xps13-9345.dts     |  4 ++
>  .../boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts  |  6 +++
>  .../dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts    |  2 +
>  .../boot/dts/qcom/x1e80100-microsoft-romulus.dtsi  |  4 ++
>  drivers/usb/typec/mux/ps883x.c                     | 47 +++++++++++++++-------
>  17 files changed, 100 insertions(+), 15 deletions(-)
> ---
> base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f
> change-id: 20260718-ps883x-disable-usb4-19b0fc13b5ab
> 
> Best regards,
> -- 
> Jens Glathe <jens.glathe@oldschoolsolutions.biz>
> 
> 
> 

* Sebastian Reichel (sre@kernel.org) wrote:
> Hello,
> 
> 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.
I'd bet it's not just qcom's suffering from this as well.

Dave

> Greetings,
> 
> -- Sebastian
> 
> > As an additional observation, the same dock with type-c cable works well
> > on Thinkpad X13s, Thinkbook 16 G7 QOY, Ideapad 5 14Q8X9, but doesn't need
> > the ps883x changes (naturally). 
> > 
> > Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
> > ---
> > Jens Glathe (5):
> >       dt-bindings: usb: parade,ps8830: Add parade,disable-usb4 property
> >       usb: typec: ps883x: Return -EOPNOTSUPP for USB4 when parade,disable-usb4 is set
> >       usb: typec: mux: ps883x: refactor DP altmode handling and support TYPEC_DP_STATE_F
> >       usb: typec: mux: ps883x: add a delay after writing config regs
> >       arm64: dts: qcom: x1: disable ps883x USB4 capability
> > 
> >  .../devicetree/bindings/usb/parade,ps8830.yaml     |  6 +++
> >  arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts         |  4 ++
> >  .../qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts  |  2 +
> >  arch/arm64/boot/dts/qcom/purwa-iot-evk.dts         |  6 +++
> >  arch/arm64/boot/dts/qcom/x1-asus-vivobook-s15.dtsi |  4 ++
> >  arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi  |  4 ++
> >  arch/arm64/boot/dts/qcom/x1-crd.dtsi               |  6 +++
> >  arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi        |  4 ++
> >  arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi   |  2 +
> >  arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi  |  4 ++
> >  arch/arm64/boot/dts/qcom/x1e001de-devkit.dts       |  6 +++
> >  .../dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi    |  4 ++
> >  .../boot/dts/qcom/x1e80100-dell-xps13-9345.dts     |  4 ++
> >  .../boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts  |  6 +++
> >  .../dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts    |  2 +
> >  .../boot/dts/qcom/x1e80100-microsoft-romulus.dtsi  |  4 ++
> >  drivers/usb/typec/mux/ps883x.c                     | 47 +++++++++++++++-------
> >  17 files changed, 100 insertions(+), 15 deletions(-)
> > ---
> > base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f
> > change-id: 20260718-ps883x-disable-usb4-19b0fc13b5ab
> > 
> > Best regards,
> > -- 
> > Jens Glathe <jens.glathe@oldschoolsolutions.biz>
> > 
> > 
> > 


-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

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

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@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:

- 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

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

Hi Sebastian,

On 7/22/26 18:03, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Jul 22, 2026 at 10:38:34AM +0200, Jens Glathe wrote:
>> 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.

...yet :) Alright, nerf patch it is. Question is how broad we need to 
specify. You have ps883x on all x1 (Hamoa and Purwa, like, Zenbook A14, 
IdeaCentre Mini X, HP Omnibook X14 fe1). So probably those compatibles: 
qcom,x1e80100, qcom,x1p42100, qcom,hamoa, qcom,purwa. Looks like a 
nerfing table :)

I will do this in v2.

with best regards

Jens

On 7/22/26 1:34 AM, Sebastian Reichel wrote:
> 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.

[...]

> 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 ;)

The PS883x is used on x86 machines too. Apart from I2C, it also
""speaks thunderbolt"" - the bus has a way for retimers to enumerate
and communicate with the routers (controllers) through a sideband
UART-like interface. But for that, it still probably needs the
platform firmware to program it into the right mode over I2C,
which Linux is unaware of (as it effectively should be).

FWIW, we do the same on X2. An MCU takes care of setting it up.

Konrad

Hi,

On Wed, Jul 22, 2026 at 10:27:57AM +0200, Konrad Dybcio wrote:
> On 7/22/26 1:34 AM, Sebastian Reichel wrote:
> > 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.
> 
> [...]
> 
> > 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 ;)
> 
> The PS883x is used on x86 machines too.

In context of x86 I was more talking about the driver than the chip
itself. The driver can only be loaded via DT. Any quirks and hacks
in the driver are unrelevant if the driver is not used by a
platform.

> Apart from I2C, it also ""speaks thunderbolt"" - the bus has a way
> for retimers to enumerate and communicate with the routers
> (controllers) through a sideband UART-like interface. But for
> that, it still probably needs the platform firmware to program it
> into the right mode over I2C, which Linux is unaware of (as it
> effectively should be).
>
> FWIW, we do the same on X2. An MCU takes care of setting it up.

Thanks for the info.

Greetings,

-- Sebastian