linux-kernel - Re: [PATCH 6/9] drm/msm/dp: Work around bogus maximum link rate

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: <CA+kEDGGVimBZDq1sa0gOXB7Vi6U8AVgD2E8mG_iTUJDce=56PA@mail.gmail.com>
Date: Fri, 18 Jul 2025 20:26:03 +0200
From: Jérôme de Bretagne <jerome.debretagne@...il.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>, Xilin Wu <sophon@...xa.com>, 
	Dale Whinham <daleyo@...il.com>, Rob Clark <robdclark@...il.com>, 
	Abhinav Kumar <quic_abhinavk@...cinc.com>, Dmitry Baryshkov <lumag@...nel.org>, 
	Sean Paul <sean@...rly.run>, Marijn Suijten <marijn.suijten@...ainline.org>, 
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, linux-arm-msm@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/9] drm/msm/dp: Work around bogus maximum link rate

On Friday, Jul 18, 2025, Dmitry Baryshkov
<dmitry.baryshkov@....qualcomm.com> wrote:
>
> On Thu, Jul 17, 2025 at 11:36:38PM +0200, Jérôme de Bretagne wrote:
> > Le jeu. 17 juil. 2025 à 23:10, Konrad Dybcio
> > <konrad.dybcio@....qualcomm.com> a écrit :
> > >
> > > On 7/17/25 10:27 PM, Jérôme de Bretagne wrote:
> > > > On 2025/7/17 04:21, Xilin Wu <sophon@...xa.com> wrote :
> > > >>
> > > >> On 2025/7/15 01:35:42, Dale Whinham wrote:
> > > >>> From: Jérôme de Bretagne <jerome.debretagne@...il.com>
> > > >>>
> > > >>> The OLED display in the Surface Pro 11 reports a maximum link rate of
> > > >>> zero in its DPCD, causing it to fail to probe correctly.
> > > >>>
> > > >>> The Surface Pro 11's DSDT table contains some XML with an
> > > >>> "EDPOverrideDPCDCaps" block that defines the max link rate as 0x1E
> > > >>> (8.1Gbps/HBR3).
> > > >>>
> > > >>> Add a quirk to conditionally override the max link rate if its value
> > > >>> is zero specifically for this model.
> > > >>>
> > > >>> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@...il.com>
> > > >>> Signed-off-by: Dale Whinham <daleyo@...il.com>
> > > >>> ---
> > > >>>   drivers/gpu/drm/msm/dp/dp_panel.c | 13 +++++++++++++
> > > >>>   1 file changed, 13 insertions(+)
> > > >>>
>
> [...]
>
> >
> > > >
> > > > Is it a feature planned in the short-medium term within the MSM driver?
> > > > If not, would a quirk like [4] be acceptable upstream in the meanwhile?
> > >
> > > I'm not a display guy, but this looks like yet another block of code
> > > begging to be commonized across DP drivers,
> >
> > I agree 100% in principle, but the 3 implementations are different today.
> >
> > > so I wouldn't expect it to be a big blocker.
> >
> > Well, it is for me :)
> >
> > > Adding a panel quirk doesn't seem in order, as the panel is /probably/
> > > very much in spec, and it's the driver bit that's missing.
> >
> > I agree that a quirk shouldn't be needed. I guess we'll work on
> > upstreaming everything else and keep an out-of-tree patch for this
> > issue for the moment That's a bit sad as this will block regular
> > users from easily installing / testing via the Ubuntu Concept ISO
> > for instance.
> >
> > Or could the quirk be accepted temporarily with good comments
> > then reverted when the driver adds the missing support? I guess
> > it would depend on the time scale of this support landing.
>
> Unforutunately, there is more than that. We should also be writing the
> LINK_RATE_SET register. So, just setting the max_bw is not enough.

Maybe I've misunderstood. When you say max_bw is not enough,
are you talking about some future driver changes or about a potential
shorter-term fix?

I can confirm that this initial simple patch (and also the updated one
reusing the quirk list [4]) is enough to get the SP11 OLED display
working whereas it doesn't probe and remains off without such a fix.

Thanks,
Jérôme

[4] https://github.com/JeromeDeBretagne/linux-surface-pro-11/commit/d265cfb
> --
> With best wishes
> Dmitry