linux-kernel - Re: [PATCH v1 5/7] arm: dts: qcom: mdm9615: remove invalid pmic subnodes compatibles

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: <07405d0d-8534-6470-21d1-26b85dbd7de0@linaro.org>
Date:   Thu, 29 Sep 2022 13:39:02 +0200
From:   Neil Armstrong <neil.armstrong@...aro.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>
Cc:     devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v1 5/7] arm: dts: qcom: mdm9615: remove invalid pmic
 subnodes compatibles

On 29/09/2022 13:12, Krzysztof Kozlowski wrote:
> On 29/09/2022 12:56, Neil Armstrong wrote:
>> On 29/09/2022 11:12, Krzysztof Kozlowski wrote:
>>> On 29/09/2022 10:29, Neil Armstrong wrote:
>>>> Hi,
>>>>
>>>> On 28/09/2022 20:03, Krzysztof Kozlowski wrote:
>>>>> On 28/09/2022 11:14, Neil Armstrong wrote:
>>>>>> The PMIC is an PM8018, but was compatible with the PM8921. Both compatibles
>>>>>> was left but it makes no sense anymore the leave both.
>>>>>
>>>>> Why? It makes sense for backwards compatibility. If you think it does
>>>>> not make sense, please say why.
>>>>
>>>> We had the same debate at submission 7y ago, some of the pm8018 new compatible
>>>> were rejected in bindings & drivers so I left both...
>>>>
>>>> As of today only the pwrkey bindings is missing, so should I resubmit the pm8018-pwrkey bidings and
>>>> drop the pm8921-pwrkey compatible ?
>>>
>>> ~7 years ago here:
>>> https://lore.kernel.org/all/20160624220748.GB11719@dtor-ws/
>>> you proposed to add something entirely different than we have here now
>>> and than we talk about.
>>>
>>> In that thread you correctly wrote:
>>> "My point of view is that the devicetree describes the hardware and need
>>> to have SoC specific compatible string since it describes the actual
>>> silicon, and drivers must make sure to handle all the SoC or family
>>> variants using the compatible string and the match data."
>>
>> And I'm happy this is still the policy! And I'm tried my best to follow this
>> in all my DT & bindings submissions, while DT-Schema helped a lot here.
>>
>>>
>>> but implemented it entirely different. Maybe you refer to different mail
>>> thread, I don't know, but that one is indeed wrong.
>>
>> In the meantime things got much better, but at that time pushing a SoC bringup
>> was a pain (I did 2 at the time, the other one is the OX810SE) and I even
>> mentioned it in a talk ([1] slides 27 to 30).
>>
>> So I added both to be sure that at some point a driver would probe against
>> one of the compatible entries...
>>
>>>
>>> The DTS looks correct unless you have some real argument that it is not.
>>>
>>> How this should be fixed? First, drop bogus entries from drivers, then
>>> document proper compatibles.
>>
>> What do you mean ? There's no point to keep the PM8921 compatibles, the gpio
> 
> I asked at beginning - why? Why there is no point to keep them?

Because the HW is an PM8018 and the addition of the PM8921 was for policy/organization/struggling-to-make-dt-merged-before-clear-dt-policy/...
so you say I should modify the Bindings to reflect the actual "pm8018", "pm8921" situation instead of changing the DT even if incorrect ?

> 
>> and PMIC bindings already enforces to only have the PM8018 compatible.
> 
> That is just partial argument because binding does not match DTS. So
> something is not correct. Why do you assume bindings are correct?

Because bindings accurately reflects HW and DT doesn't.

> 
>>
>> The only issue is about the PM8018 pwrkey, where the solution would be
>> to actually re-submit [1] by documenting qcom,pm8018-pwrkey and adding the entry
>> in the drivers/input/misc/pmic8xxx-pwrkey.c driver.
>>
>> Or maybe I missed something.
>>
>> [1] https://www.slideshare.net/superna/elce-2016-neil-armstrong-no-its-never-too-late-to-upstream-your-legacy-linux-based-platform
>> [2] https://lore.kernel.org/all/1466759887-25394-3-git-send-email-narmstrong@baylibre.com/
> 
> So let's repeat again: the patch [2] looks wrong. The qcom,pm8018-pwrkey
> and qcom,pm8921-pwrkey are compatible.

Ok, I need time to understand, I'm highly confused now.

> 
> Best regards,
> Krzysztof
>