linux-kernel - Re: [PATCH 11/11] arm64: dts: qcom: qcm6490: Add device-tree for Fairphone 5

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: <5f05c76e-e74e-4954-a729-3ed2a1d33605@linaro.org>
Date:   Sat, 2 Sep 2023 13:45:35 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Luca Weiss <luca.weiss@...rphone.com>,
        cros-qcom-dts-watchers@...omium.org,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
        linux-pm@...r.kernel.org
Subject: Re: [PATCH 11/11] arm64: dts: qcom: qcm6490: Add device-tree for
 Fairphone 5

On 1.09.2023 16:27, Luca Weiss wrote:
> On Wed Aug 30, 2023 at 12:45 PM CEST, Konrad Dybcio wrote:
>> On 30.08.2023 11:58, Luca Weiss wrote:
>>> Add device tree for the Fairphone 5 smartphone which is based on
>>> the QCM6490 SoC.
>>>
>>> Supported features are, as of now:
>>> * Bluetooth
>>> * Debug UART
>>> * Display via simplefb
>>> * Flash/torch LED
>>> * Flip cover sensor
>>> * Power & volume buttons
>>> * RTC
>>> * SD card
>>> * USB
>>> * Various plumbing like regulators, i2c, spi, etc
>>>
>>> Signed-off-by: Luca Weiss <luca.weiss@...rphone.com>
>>> ---
[...]

>>> +	panel: panel {
>>> +		compatible = "boe,rm692e5";
>> Undocumented compatbile
> 
> Not quite sure how to document this properly. This dummy panel node is
> used for the simplefb/simpledrm so that user space can get panel
> dimensions already.
> 
> This approach of a separate panel node was apparently preferred when the
> functionality was upstreamed but of course as can be seen this panel
> node is very barebones where many properties are not present which would
> be needed with the full panel driver (once it's working).
> 
> Also for example for the bindings I think width-mm and height-mm won't
> be needed anymore since that information will be provided by the driver
> then.
> 
> Please let me know how/where to document this.
As discussed offline, the workflow here would be to oneOf: (wink)

- wait until there's a proper driver and create a binding based on
  what you know (because you have a working driver and can test it)
  is necessary for it to function

- create the binding for that display panel + driver ic combo in
  advance and pray that whatever you put there will be enough when
  you take upon yourself to write the driver

I'd suggest dropping these properties (or keeping them downstream or
something) for now, the display should not be terribly hard to bring
up properly, let's hope that can be done soon!

> I'm aware, but will work on this later since it's not useful without
> USB-C role switching and working audio.
You can still peek at it in like sysfs or so, but up to you.


Konrad