linux-kernel - Re: [PATCH 17/32] dt-bindings: pinctrl: qcom,msm8909-tlmm: do not require function on non-GPIOs

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: <cdfe6f83-266a-de8b-d518-cc8b7fd45732@linaro.org>
Date:   Mon, 26 Sep 2022 08:48:09 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Stephan Gerhold <stephan@...hold.net>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Sricharan R <sricharan@...eaurora.org>,
        Shawn Guo <shawn.guo@...aro.org>,
        Vinod Koul <vkoul@...nel.org>,
        krishna Lanka <quic_vamslank@...cinc.com>,
        Sivaprakash Murugesan <sivaprak@...eaurora.org>,
        linux-arm-msm@...r.kernel.org, linux-gpio@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 17/32] dt-bindings: pinctrl: qcom,msm8909-tlmm: do not
 require function on non-GPIOs

On 25/09/2022 16:00, Stephan Gerhold wrote:
>> +    allOf:
>> +      - $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state"
>> +      - if:
>> +          properties:
>> +            pins:
>> +              pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-7])$"
>> +        then:
>> +          required:
>> +            - function
>>  
> 
> Is it possible to place this into qcom,tlmm-common.yaml? If the pattern
> is only used to make "function" required for GPIOs, then it should not
> matter if it matches just the prefix ("^gpio") or the exact set of
> allowed GPIO numbers. The definition of the "pins" property will already
> take care of validating those.

Hm, very good idea.

> 
> Or are there some Qcom SoCs where a GPIO without "function" is valid?

Quick look at drivers says there is no such case. I can try adding it to
common schema and look for errors.


Best regards,
Krzysztof