linux-kernel - Re: [PATCH v2 09/13] arm64: dts: qcom: sdm845-lg-judyln: Add fb

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: <ac2d419d-a1b4-4b3f-a07a-4f5d047901aa@minlexx.ru>
Date: Wed, 17 Sep 2025 17:54:55 +0300
From: Alexey Minnekhanov <alexeymin@...lexx.ru>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Paul Sajna <sajattack@...tmarketos.org>,
 Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, David Heidelberg <david@...t.cz>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, phone-devel@...r.kernel.org,
 Amir Dahan <system64fumo@...tonmail.com>,
 Christopher Brown <crispybrown@...il.com>
Subject: Re: [PATCH v2 09/13] arm64: dts: qcom: sdm845-lg-judyln: Add fb_panel
 dimensions

On 17.09.2025 16:59, Konrad Dybcio wrote:
> On 9/17/25 3:09 AM, Paul Sajna wrote:
>> Add display dimensions for proper scaling
>>
>> Signed-off-by: Paul Sajna <sajattack@...tmarketos.org>
>> ---
>>   arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
>> index e84b45ed82fd13850ea7ec1f34ddac5b59fc1434..8c1692f86e6ceea7b718361965e78f95d39373bb 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
>> +++ b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
>> @@ -23,6 +23,13 @@ framebuffer@...00000 {
>>   			format = "a8r8g8b8";
>>   			lab-supply = <&lab>;
>>   			ibb-supply = <&ibb>;
>> +
>> +			panel = <&fb_panel>;
>> +
>> +			fb_panel: fb-panel {
>> +				width-mm = <65>;
>> +				height-mm = <140>;
> 
> It'd be nicer if you moved these properties to the actual panel
> node (the DSI one) and referenced that one instead (I think that
> should work)
> 
> Konrad
> 

Hi!

First of all this code doesn't work well for upstream, because it causes
errors with dtbs checks like:

   framebuffer@...00000 (simple-framebuffer): 'fb-panel' does not match 
any of the regexes: '^[a-zA-Z0-9-]+-supply$', '^pinctrl-[0-9]+$'

^^ The subnode is not allowed by bindings.

The whole reasoning for this little hack is that the upstream
recommended approach to solve the "unknown DPI" for framebuffer issue
is to put width-mm, height-mm into real panel node and and reference it
in simple-fb node - sonds very nice in theory, but also doesn't work
well in practice, and explanation why will take a bit longer, please
bear with me for a minute.

If we do as recommended, device tree structure will look like this:

  framebuffer@...00000 {
      ...
      panel = <&display_panel>;
  };

  soc@0 {
      ....

      mdss {
          ...
          dsi0 {
              ...
              display_panel: panel@0 {
                  reg = <0>;
                  compatible = "lg,sw49410";
                  ...
                  width-mm = <65>;
                  height-mm = <140>;
              };
          ...

Then, to my understanding, due to how fw-devlink works, the panel=<&..>
link from simplefb node to display_panel node creates a probe-time
dependency, so that the whole display stack probes first: MDSS, DSI
controller, maybe even Adreno GPU, *AND* panel all probe first, thus
making the mere existence of simple-framebuffer pointless.

Additionally, simple-framebuffer probes succesfully after that,
creating "second GPU" entry in as /dev/dri/card1 making it look like
system has 2 GPUS, which confuses almost every window manager in
userspace later. Normally, if simplefb probes first, it gets unloaded
and replaced by MDSS and does not cause any chaos. In the end the whole
situation looks even more silly than the fake panel subnode hack.

Therefore for upstream I'd recommend to just drop any fb-panel hacks and
to not use panel=<&...> with reference to real panel either.

It would all be much much easier if we could just specify width-mm/
height-mm directly in simplefb node, but DT maintainers rejected that idea.

---
Regards,
Alexey Minnekhanov