Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 4 Nov 2022 04:03:26 +0200
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        netdev@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] dt-bindings: net: nxp,sja1105: document spi-cpol/cpha
Message-ID: <20221104020326.4l63prl7vxgi3od7@skbuf>
References: <20221102185232.131168-1-krzysztof.kozlowski@linaro.org>
 <20221103233319.m2wq5o2w3ccvw5cu@skbuf>
 <698c3a72-f694-01ac-80ba-13bd40bb6534@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <698c3a72-f694-01ac-80ba-13bd40bb6534@linaro.org>
Precedence: bulk

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.