linux-kernel - Re: drm/msm/dp: Introduce link training per-segment for LTTPRs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMcHhXpstN-g5idywuJbUxeKNqMUTTV=HQ6qvo0_Ann+-mEUbA@mail.gmail.com>
Date: Tue, 29 Apr 2025 09:29:08 +0200
From: Aleksandrs Vinarskis <alex.vinarskis@...il.com>
To: Abel Vesa <abel.vesa@...aro.org>
Cc: Johan Hovold <johan@...nel.org>, Dmitry Baryshkov <lumag@...nel.org>, linux-arm-msm@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org, dmitry.baryshkov@....qualcomm.com, 
	Rob Clark <robdclark@...il.com>, Abhinav Kumar <quic_abhinavk@...cinc.com>, 
	Sean Paul <sean@...rly.run>, Marijn Suijten <marijn.suijten@...ainline.org>, 
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, laurentiu.tudor1@...l.com
Subject: Re: drm/msm/dp: Introduce link training per-segment for LTTPRs

On Tue, 29 Apr 2025 at 08:52, Abel Vesa <abel.vesa@...aro.org> wrote:
>
> On 25-04-28 20:23:45, Aleksandrs Vinarskis wrote:
> > On Mon, 28 Apr 2025 at 16:17, Abel Vesa <abel.vesa@...aro.org> wrote:
> > >
> > > The change itself makes sense though and I think makes sense to be marked as a fix.
> >
> > Just to confirm, you mean to mark as fix only the 1st patch, correct?
> > Since it's obvious now that the currently present partial LTTPR
> > support did not break anything that used to work.
>
> Well, the way I see it, the LTTPR support is broken on some specific
> docks, even if it works in most cases. And since this fix improves
> the already working cases and fixes broken ones, yes, add the Fixes tag
> to the 1st patch only.

That is not entirely correct. Current LTTPR initialization [1] does
properly set LTTPR to transparent, and then non transparent [2]. In
this case LTTPRs are expected to be trained per link, but are not. It
is reasonable that LTTPR(s) may not work as expected, as they are not
link trained as expected, and now they are not in transparent mode
(anymore).

It does work with X1E onboard LTTPR and a simple external display, but
that is about it. It does not work with _any_ dock that has LTTPR. Or
basically anything that has yet another LTTPR in its way. Given that
max length of DP cable at full bandwidth is 2m, and docks typically
have 50-100cm built in cable for PC connection, not counting outgoing
video connection, this basically means that any DP1.4 and onwards
docking station (not an adapter/dongle) does not work.
Additionally, it appears some fancy monitors with Thundebolt/DP alt
mode ports instead of just DP alt mode also have a retimer onboard
(might have to do with particular monitor support DP-Out for MST), and
also do not work in current setup.
Additionally, it was recently found out that without this series, rhs
USB Type-C on Lenovo Yoga Slim7x does not work either, which likely
implies that IO board on the flex cable for that connector features
yet another retimer.

I wouldn't say it's broken on some specific docks, rather the other
way around, current LTTPR support is limited to 1x LTTPR onboard X1E
devices and nothing else.

Not disagrees wrt to Fixes tag, just wanted to clarify current state
and the impact of this change as it is not limited to just 'specific
docks'.

[1] https://github.com/torvalds/linux/blob/v6.15-rc4/drivers/gpu/drm/msm/dp/dp_display.c#L378
[2] https://github.com/torvalds/linux/blob/v6.15-rc4/drivers/gpu/drm/display/drm_dp_helper.c#L2926

>
> I'd even send that first patch separately to ease the merging, but that's
> probably just me.
>
> >
> > Thanks,
> > Alex
> >
>
> Abel