linux-kernel - Re: [PATCH v3 1/6] dt-bindings: regulator: qcom,spmi-regulator: Convert to dtschema

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: <bc13e57f-9701-80c9-8c7a-e491fbcfd181@linaro.org>
Date:   Wed, 18 May 2022 15:34:23 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Robert Marko <robimarko@...il.com>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        lgirdwood@...il.com, broonie@...nel.org,
        Rob Herring <robh+dt@...nel.org>,
        krzysztof.kozlowski+dt@...aro.org,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Devicetree List <devicetree@...r.kernel.org>
Subject: Re: [PATCH v3 1/6] dt-bindings: regulator: qcom,spmi-regulator:
 Convert to dtschema

On 18/05/2022 15:25, Robert Marko wrote:
>> I think we misunderstood each other. Old bindings indeed did not require
>> the interrupts, although if present they should be always defined.
>> Therefore here you should specify number of items and their names.
> 
> Yeah, I think we are misunderstanding each other.
> 
> Old text-based bindings specified the interrupts, but no naming or
> number was enforced,
> so I looked into the driver to see what is going on.
> Only pm8941 has interrupts defined in the driver and DTS, so I added
> those based on compatible
> matching, the same as with supplies.
> My logic was that it was only valid for interrupts to be described if
> PM8941 was used as describing
> interrupts for other regulator models will do nothing.

Indeed, you're right, thanks for explanation. Your patch in such case is
correct way of conversion but allows any number of interrupts with any
names, so it's to relaxed. Maybe then better go to previous version,
where these interrupts were defined only for one variant. For other
variants they would fail on as unevaluated?

Best regards,
Krzysztof