linux-kernel - Re: [PATCH 1/2] dt-bindings: nfc: use spi-peripheral-props.yaml

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ea684136-bdbb-1b2c-35d3-64fdbd1d1764@linaro.org>
Date:   Thu, 28 Jul 2022 18:31:32 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Rob Herring <robh@...nel.org>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jérôme Pouiller <jerome.pouiller@...abs.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Ajay Singh <ajay.kathat@...rochip.com>,
        linux-wireless@...r.kernel.org, devicetree@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        Rob Herring <robh+dt@...nel.org>,
        Tony Lindgren <tony@...mide.com>,
        Kalle Valo <kvalo@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Adham Abozaeid <adham.abozaeid@...rochip.com>,
        Mark Greer <mgreer@...malcreek.com>
Subject: Re: [PATCH 1/2] dt-bindings: nfc: use spi-peripheral-props.yaml

On 28/07/2022 17:18, Rob Herring wrote:
> On Wed, 27 Jul 2022 18:41:29 +0200, Krzysztof Kozlowski wrote:
>> Instead of listing directly properties typical for SPI peripherals,
>> reference the spi-peripheral-props.yaml schema.  This allows using all
>> properties typical for SPI-connected devices, even these which device
>> bindings author did not tried yet.
>>
>> Remove the spi-* properties which now come via spi-peripheral-props.yaml
>> schema, except for the cases when device schema adds some constraints
>> like maximum frequency.
>>
>> While changing additionalProperties->unevaluatedProperties, put it in
>> typical place, just before example DTS.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>
>> ---
>>
>> Technically, this depends on [1] merged to SPI tree, if we want to
>> preserve existing behavior of not allowing SPI CPHA and CPOL in each of
>> schemas in this patch.
>>
>> If this patch comes independently via different tree, the SPI CPHA and
>> CPOL will be allowed for brief period of time, before [1] is merged.
>> This will not have negative impact, just DT schema checks will be
>> loosened for that period.
> 
> I don't think these need to go via the same tree.

Yeah, I wanted to express it that almost no impact is expected if it
goes independently. I could be more explicit here.


Best regards,
Krzysztof