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: <3fa19362-118b-232e-0baf-ee365fa2f2e2@linaro.org>
Date:   Thu, 29 Sep 2022 13:59:50 +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:47, Krzysztof Kozlowski wrote:
> On 29/09/2022 13:39, Neil Armstrong wrote:
>>>>> 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 ?
> 
> Yes, this is what I already wrote:
> 
> "How this should be fixed? First, drop bogus entries from drivers, then
> document proper compatibles."
> 
>>>> 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.
> 
> That's not really an answer... Bindings are correct because they are
> correct? What is exactly correct in the bindings? How they reflect the
> HW in a proper way, while DTS does not?
> 
> Or let's focus on actual hardware - what are the properties of the
> hardware which indicate that DTS is wrong?

The actual PMIC is an PM8018

> 
> Best regards,
> Krzysztof
> 

Neil