linux-kernel - Re: [PATCH v2 2/4] Revert "drm/panel-edp: Add SDC ATNA45AF01"

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: <d1603248-afe8-4594-9e2e-81ba208dff00@linaro.org>
Date: Mon, 15 Jul 2024 15:01:57 +0200
From: Neil Armstrong <neil.armstrong@...aro.org>
To: Stephan Gerhold <stephan.gerhold@...aro.org>
Cc: Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konrad.dybcio@...aro.org>,
 Jessica Zhang <quic_jesszhan@...cinc.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Douglas Anderson <dianders@...omium.org>,
 dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 Abel Vesa <abel.vesa@...aro.org>, Johan Hovold <johan@...nel.org>
Subject: Re: [PATCH v2 2/4] Revert "drm/panel-edp: Add SDC ATNA45AF01"

On 15/07/2024 14:54, Stephan Gerhold wrote:
> On Mon, Jul 15, 2024 at 02:42:12PM +0200, Neil Armstrong wrote:
>> On 15/07/2024 14:15, Stephan Gerhold wrote:
>>> This reverts commit 8ebb1fc2e69ab8b89a425e402c7bd85e053b7b01.
>>>
>>> The panel should be handled through the samsung-atna33xc20 driver for
>>> correct power up timings. Otherwise the backlight does not work correctly.
>>>
>>> We have existing users of this panel through the generic "edp-panel"
>>> compatible (e.g. the Qualcomm X1E80100 CRD), but the screen works only
>>> partially in that configuration: It works after boot but once the screen
>>> gets disabled it does not turn on again until after reboot. It behaves the
>>> same way with the default "conservative" timings, so we might as well drop
>>> the configuration from the panel-edp driver. That way, users with old DTBs
>>> will get a warning and can move to the new driver.
>>>
>>> Reviewed-by: Douglas Anderson <dianders@...omium.org>
>>> Signed-off-by: Stephan Gerhold <stephan.gerhold@...aro.org>
>>> ---
>>>    drivers/gpu/drm/panel/panel-edp.c | 2 --
>>>    1 file changed, 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
>>> index 3a574a9b46e7..d2d682385e89 100644
>>> --- a/drivers/gpu/drm/panel/panel-edp.c
>>> +++ b/drivers/gpu/drm/panel/panel-edp.c
>>> @@ -1960,8 +1960,6 @@ static const struct edp_panel_entry edp_panels[] = {
>>>    	EDP_PANEL_ENTRY('L', 'G', 'D', 0x05af, &delay_200_500_e200_d200, "Unknown"),
>>>    	EDP_PANEL_ENTRY('L', 'G', 'D', 0x05f1, &delay_200_500_e200_d200, "Unknown"),
>>> -	EDP_PANEL_ENTRY('S', 'D', 'C', 0x416d, &delay_100_500_e200, "ATNA45AF01"),
>>> -
>>>    	EDP_PANEL_ENTRY('S', 'H', 'P', 0x1511, &delay_200_500_e50, "LQ140M1JW48"),
>>>    	EDP_PANEL_ENTRY('S', 'H', 'P', 0x1523, &delay_80_500_e50, "LQ140M1JW46"),
>>>    	EDP_PANEL_ENTRY('S', 'H', 'P', 0x153a, &delay_200_500_e50, "LQ140T1JH01"),
>>>
>>
>> How will we handle current/old crd DT with new kernels ?
>>
> 
> I think this is answered in the commit message:
> 
>>> We have existing users of this panel through the generic "edp-panel"
>>> compatible (e.g. the Qualcomm X1E80100 CRD), but the screen works only
>>> partially in that configuration: It works after boot but once the screen
>>> gets disabled it does not turn on again until after reboot. It behaves the
>>> same way with the default "conservative" timings, so we might as well drop
>>> the configuration from the panel-edp driver. That way, users with old DTBs
>>> will get a warning and can move to the new driver.
> 
> Basically with the entry removed, the panel-edp driver will fallback to
> default "conservative" timings when using old DTBs. There will be a
> warning in dmesg, but otherwise the panel will somewhat work just as
> before. I think this is a good way to remind users to upgrade.

I consider this as a regression

> 
>> Same question for patch 3, thie serie introduces a bindings that won't be valid
>> if we backport patch 3. I don't think patch should be backported, and this patch
>> should be dropped.
> 
> There would be a dtbs_check warning, yeah. Functionally, it would work
> just fine. Is that reason enough to keep display partially broken for
> 6.11? We could also apply the minor binding change for 6.11 if needed.

I don't know how to answer this, I'll let the DT maintainer comment this.

The problem is I do not think we can pass the whole patchset as fixes
for v6.11, patches 2 & 3 could, patches 1 & 4 definitely can't.

Neil

> 
> I'm also fine if this just goes into 6.12 though.
> 
> Thanks,
> Stephan