On Wed, Oct 05, 2022 at 10:09:06AM +0200, Krzysztof Kozlowski wrote:

quoted

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.

Then still the /spi node does not seem related. If I understand
correctly, your device described in this bindings is a child of soc@0.
Sounds fine. How that soc@0 is connected to the parent - via SPI or
whatever - is not related to this binding, is it? It is related to the
soc binding, but not here.

It's an example, it's meant to be informative. It is the first DSA
driver of its kind. When everybody else ATM puts the ethernet-switch node
under the &spi controller node, this puts it under &spi/soc@<chip-select>/,
for reasons that have to do with scalability. If the examples aren't a
good place to make this more obvious, I don't know why we don't just
tell people to RTFD.

quoted

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.

Is there a question here to me? What shall I do with this paragraph? You
know, I do not have a problem of lack of material to read...

For mscc,vsc7514-switch we have a switchdev driver. For mscc,vsc7512-switch,
Colin is working on a DSA driver. Their dt-bindings currently live in
different folders. The mscc,vsc7514-switch can also be used together
with a DSA driver, and support for that will inevitably be added. When
it will, how and where do you recommend the dt-bindings should be added?
In net/dsa/mscc,ocelot.yaml, together with the other switches used in
DSA mode, or in net/mscc,vsc7514-switch.yaml, because its compatible
string already exists there? We can't have a compatible string present
in multiple schemas, right?

This matters because it has implications upon what Colin should do with
the mscc,vsc7512-switch. If your answer to my question is "add $ref: dsa.yaml#
to net/mscc,vsc7514-switch.yaml", then I don't see why we wouldn't do
that now, and wait until the vsc7514 to make that move anyway.