linux-kernel - Re: [PATCH v2] dt-bindings: net: nxp,sja1105: document spi-cpol/cpha

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] [day] [month] [year] [list]

Date:   Fri, 4 Nov 2022 19:31:20 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] dt-bindings: net: nxp,sja1105: document spi-cpol/cpha

On Fri, Nov 04, 2022 at 01:13:34PM -0400, Krzysztof Kozlowski wrote:
> On 04/11/2022 12:52, Vladimir Oltean wrote:
> > Ok, then this patch is not correct either. The "nxp,sja1105*" devices
> > need to have only "spi-cpha", and the "nxp,sja1110*" devices need to
> > have only "spi-cpol".
> 
> Sure, I'll add allOf:if:then based on your input.

No, actually my input is that removing such core properties as spi-cpol/
spi-cpha from spi-peripheral-props.yaml challenges the whole purpose of
that schema fragment.

I can go back at it and complain all day that my peripheral doesn't need
spi-cs-high, spi-lsb-first, spi-rx-bus-width, spi-tx-bus-width,
stacked-memories, parallel-memories and what not. Or that the SJA1105
switch will never need the properties of nvidia,tegra210-quad-peripheral-props.yaml#,
because the former speaks SPI and the latter speaks QSPI (for flashes).
By this logic, eventually that schema will be reduced to nothing.

Yet I don't believe that including just the intersection of properties
that actually lead to functional hardware for all peripherals was the
*intention* of that schema. Just the properties which are semantically
valid, and cpol/cpha are absolutely semantically valid.
The justification that cpol/cpha are "not valid" for some peripherals
(or correctly said, those peripherals only work in mode 0) is very weak
to begin with, and restricting the SPI modes to only those that
physically work should IMO be the duty of the hardware schema and not
the common schema. The common schema just provides the type and
description, the hardware gives the valid ranges.