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 for Android: free password hash cracker in your pocket

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

Message-ID: <0bb0c437-e680-4160-b98f-efb816c9f049@oss.qualcomm.com>
Date: Fri, 18 Jul 2025 21:30:54 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Jérôme de Bretagne <jerome.debretagne@...il.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 18/07/2025 21:26, Jérôme de Bretagne wrote:
> 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.

These parts were changed in eDP 1.4 and then 1.5, but basically, if 
MAX_LINK_RATE is 0, the driver should also write LINK_RATE_SET register. 
See how it's handled by the intel or AMD drivers.

> 
> Thanks,
> Jérôme
> 
> [4] https://github.com/JeromeDeBretagne/linux-surface-pro-11/commit/d265cfb
>> --
>> With best wishes
>> Dmitry


-- 
With best wishes
Dmitry