public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
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
Date: Fri, 4 Nov 2022 19:31:20 +0200	[thread overview]
Message-ID: <20221104173120.ho6a624lqnzboz2g@skbuf> (raw)
In-Reply-To: <61945062-4261-ba3d-0d39-8c1cc46ad33b@linaro.org>

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.

  reply	other threads:[~2022-11-04 17:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-02 18:52 [PATCH v2] dt-bindings: net: nxp,sja1105: document spi-cpol/cpha Krzysztof Kozlowski
2022-11-03 23:33 ` Vladimir Oltean
2022-11-04  1:44   ` Krzysztof Kozlowski
2022-11-04  2:03     ` Vladimir Oltean
2022-11-04 13:09       ` Krzysztof Kozlowski
2022-11-04 16:52         ` Vladimir Oltean
2022-11-04 17:13           ` Krzysztof Kozlowski
2022-11-04 17:31             ` Vladimir Oltean [this message]
2022-11-04 17:00         ` Vladimir Oltean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221104173120.ho6a624lqnzboz2g@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox