Message-ID: <20221004160135.lqugs6cf5b7fwkxq@skbuf>
Date:   Tue, 4 Oct 2022 19:01:35 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Colin Foster <colin.foster@...advantage.com>,
        linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, netdev@...r.kernel.org,
        Russell King <linux@...linux.org.uk>,
        Linus Walleij <linus.walleij@...aro.org>,
        UNGLinuxDriver@...rochip.com,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Lee Jones <lee@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Subject: Re: [PATCH v3 net-next 12/14] dt-bindings: net: dsa: ocelot: add
 ocelot-ext documentation

On Tue, Oct 04, 2022 at 04:59:02PM +0200, Krzysztof Kozlowski wrote:
> On 04/10/2022 14:15, Vladimir Oltean wrote:
> > On Tue, Oct 04, 2022 at 01:19:33PM +0200, Krzysztof Kozlowski wrote:
> >>> +  # Ocelot-ext VSC7512
> >>> +  - |
> >>> +    spi {
> >>> +        soc@0 {
> >>
> >> soc in spi is a bit confusing.
> > 
> > Do you have a better suggestion for a node name? This is effectively a
> > container for peripherals which would otherwise live under a /soc node,
> 
> /soc node implies it does not live under /spi node. Otherwise it would
> be /spi/soc, right?

Did you read what's written right below? I can explain if you want, but
there's no point if you're not going to read or ask other clarification
questions.

> > if they were accessed over MMIO by the internal microprocessor of the
> > SoC, rather than by an external processor over SPI.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The /spi/soc@0 node actually has a compatible of "mscc,vsc7512" which
Colin did not show in the example (it is not "simple-bus"). It is covered
by Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml. Still waiting
for a better suggestion for how to name the mfd container node.

> >> How is this example different than previous one (existing soc example)?
> >> If by compatible and number of ports, then there is no much value here.
> > 
> > The positioning relative to the other nodes is what's different.
> 
> Positioning of nodes is not worth another example, if everything else is
> the same. What is here exactly tested or shown by example? Using a
> device in SPI controller?

Everything is not the same, it is not the same hardware as what is currenly
covered by Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml.
The "existing soc example" (mscc,vsc9953-switch) has a different port
count, integration with a different SERDES, interrupt controller, pin
controller, things like that. The examples already differ in port count
and phy-mode values, I expect they will start diverging more in the
future. If you still believe it's not worth having an example of how to
instantiate a SPI-controlled VSC7512 because there also exists an
example of an MMIO-controlled VSC9953, then what can I say.

------ cut here ------

Unrelated to your "existing soc example" (the VSC9953), but relevant and
you may want to share your opinion on this:

The same hardware present in the VSC7514 SoC can also be driven by an
integrated MIPS processor, and in that case, it is indeed expected that
the same dt-bindings cover both the /soc and the /spi/soc@0/ relative
positioning of their OF node. This is true for simpler peripherals like
"mscc,ocelot-miim", "mscc,ocelot-pinctrl", "mscc,ocelot-sgpio". However
it is not true for the main switching IP of the SoC itself.

When driven by a switchdev driver, by the internal MIPS processor (the
DMA engine is what is used for packet I/O), the switching IP follows the
Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml binding
document.

When driven by a DSA driver (external processor, host frames are
redirected through an Ethernet port instead of DMA controller),
the switching IP follows the Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml
document.

The switching IP is special in this regard because the hardware is not
used in the same way. The DSA dt-binding also needs the 'ethernet'
phandle to be present in a port node. The different placement of the
bindings according to the use case of the hardware is a bit awkward, but
is a direct consequence of the separation between DSA and pure switchdev
drivers that has existed thus far (and the fact that DSA has its own
folder in the dt-bindings, with common properties in dsa.yaml and
dsa-port.yaml etc). It is relatively uncommon for a switching IP to have
provisioning to be used in both modes, and for Linux to support both
modes (using different drivers), yet this is what we have here.

Powered by blists - more mailing lists