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

Date:   Fri, 4 Nov 2022 04:03:26 +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 Thu, Nov 03, 2022 at 09:44:36PM -0400, Krzysztof Kozlowski wrote:
> > Don't these belong to spi-peripheral-props.yaml?
> 
> No, they are device specific, not controller specific. Every device
> requiring them must explicitly include them.
> 
> See:
> https://lore.kernel.org/all/20220816124321.67817-1-krzysztof.kozlowski@linaro.org/
> 
> Best regards,
> Krzysztof
> 

I think you really mean to link to:
https://lore.kernel.org/all/20220718220012.GA3625497-robh@kernel.org/

oh and btw, doesn't that mean that the patch is missing
Fixes: 233363aba72a ("spi/panel: dt-bindings: drop CPHA and CPOL from common properties")
?

but I'm not sure I understand the reasoning? I mean, from the
perspective of the common schema, isn't it valid to put "spi-cpha" on a
SPI peripheral OF node even if the hardware doesn't support it, in the
same way that it's valid to put spi-max-frequency = 1 GHz even if the
hardware doesn't support it? Or maybe I'm missing the point of
spi-peripheral-props.yaml entirely? Since when is stacked-memories/
parallel-memories something that should be accepted by all schemas of
all SPI peripherals (for example here, an Ethernet switch)?
I think that spi-cpha/spi-cpol belongs to spi-peripheral-props.yaml just
as much as the others do.

The distinction "device specific, not controller specific" is arbitrary
to me. These are settings that the controller has to make in order to
talk to that specific peripheral. Same as many others in that file.