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: <CAMcHhXrDEVrM4fEyMwZ9TDgqgY=s_mTcKZMacCoUuZ2fa8FhWg@mail.gmail.com>
Date: Tue, 29 Apr 2025 12:57:16 +0200
From: Aleksandrs Vinarskis <alex.vinarskis@...il.com>
To: Johan Hovold <johan@...nel.org>
Cc: Abel Vesa <abel.vesa@...aro.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 10:03, Johan Hovold <johan@...nel.org> wrote:
>
> On Tue, Apr 29, 2025 at 10:50:55AM +0300, Abel Vesa wrote:
> > On 25-04-29 09:23:46, Johan Hovold wrote:
> > > On Mon, Apr 28, 2025 at 05:17:21PM +0300, Abel Vesa wrote:
> > > > On 25-04-28 14:47:04, Johan Hovold wrote:
> > > > > On Mon, Apr 28, 2025 at 11:06:39AM +0200, Aleksandrs Vinarskis wrote:
> > > > > > On Mon, 28 Apr 2025 at 09:45, Johan Hovold <johan@...nel.org> wrote:
>
> > > > > > > Does this mean that the incomplete LTTPR support in 6.15-rc1 broke
> > > > > > > adapters or docks with retimers in transparent mode?
>
> > > Ok, but my concern is if they may have worked in a default transparent
> > > mode.
> >
> > But if they are by default in transparent mode, doing the setup to
> > transparent mode will not break it in any way.
>
> It looks like it will, see below.
>
> > > > X13s doesn't have LTTPRs on-board so when reading the caps, LTTPRs count
> > > > would return 0 and none of the of the transparent/non-transparent setup
> > > > would happen.
> > >
> > > But this is the crux; does any off-board LTTPRs in transparent mode add
> > > to the count or not? If they don't, how would you ever learn that there
> > > are any LTTPRs? If they do, it seems we may have a problem here.
> >
> > Count gets increased either way. It doesn't matter if they are in
> > transparent mode or not.
>
> Thanks for confirming. So then it seems we do have a problem as since
> 6.15-rc1 drm_dp_lttpr_init() will switch all LTTPRs to non-transparent
> mode.

In this case, let me add Fixes to the entire series. Do you think we
could land it in 6.15-rcX then? The second option proposed to roll
back current LTTPR support and wait until 6.16 will completely break
DP output on all X1E, so it's very undesirable.

This series was tested quite a bit on at least the X1E/X1P devices,
both with and without docking stations, as it is also (v2 iirc) part
of Ubuntu's concept tree since little over a month ago. You have
confirmed that x13s also works with this change but without a docking
station. If someone could confirm that x13s with this change does work
with a docking station as well, it would be safe to merge the entire
series as fix to 6.15, correct? I could reach out on #aarch64-laptops,
perhaps someone has both x13s (or another qcom-based non X1(E) device)
and a docking station.

Thanks,
Alex

>
> Johan