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]

Date:   Wed, 18 May 2022 16:00:00 +0200
From:   Robert Marko <robimarko@...il.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
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 Wed, 18 May 2022 at 15:34, Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> 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?

Yeah, that was my intention with not having interrupts as the generic property.
I will remove them as generic property and only allow them per
compatible, cause I tested
adding interrupts to a PMIC DTS that does not allow them and make
dtbs_check will
warn about those being unevaluated.

Regards,
Robert
>
> Best regards,
> Krzysztof