Re: [net-next 2/2] net: dsa: realtek: load switch variants on demand

[Vladimir Oltean <olteanv@gmail.com>]

On Thu, Dec 07, 2023 at 11:46:46PM -0300, Luiz Angelo Daros de Luca wrote:
> The device-tree bindings should delineate the hardware characteristics
> rather than specifying the implementation details of a particular
> driver. The requirement of an "mdio" node with a compatible string
> such as "realtek,smi-mdio" may be misleading, implying a potential
> correlation between the host-switch interface (SMI, SPI, or MDIO) and
> a specific user MDIO it describes. It's important to note that how we
> describe the user mdio could vary for other future switch families,
> but not with a distinct management interface.

Agree, "realtek,smi-mdio" is not a great compatible string. But it is an
established compatible string.

> I am currently conducting tests using the same user MDIO driver for
> both realtek-smi and realtek-mdio. However, it's noteworthy that
> unlike realtek-smi, the current user MDIO for realtek-mdio does not
> require a compatible string; only a node named "mdio". Realtek-mdio is
> presently utilizing the generic DSA user MDIO, but you mentioned it's
> not considered a "core functionality." I assume this implies I
> shouldn't depend on it. That's the reason for my switch to the
> existing user MDIO driver from realtek-smi.
> 
> Regarding the absence of a compatible string for realtek-mdio, we have
> a few options: introducing a new compatible string exclusively for
> realtek-mdio, such as "realtek,mdio-mdio"; creating a new generic one
> for both interfaces like "realtek,user-mdio" or "rtl836x-user-mdio";

The naming choice really looks like the secondary problem here.
But what about "realtek,rtl8365mb-mdio" and "realtek,rtl8366rb-mdio" as
a secondary compatible string for SMI, and primary compatible string for
MDIO-connected switches?

> or simply ignore the compatible string, as you suggested. However, if
> I opt to ignore it, I presume I should retrieve that node solely based
> on the node name. That's what I'm after. Is my understanding correct?

You could do that. There's a very high chance that the node was named
"mdio". The schema says it should be called "mdio", _and_ be compatible
with realtek,smi-mdio. If anyone comes and complains (very unlikely),
just say "hey, even Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
said you should name the node 'mdio'"!

> I'll post a new series that is still compatible both with old HW
> descriptions and the device-tree bindings. In that way, I'll not touch
> the docs.

> However, given that the compatible string is unnecessary to describe
> the hardware, and after we modify the code to disregard it, it is
> awkward for the binding documentation to request a compatible string
> that serves no purpose. Shouldn't we consider updating this
> requirement at some point?
> 
> Regards,
> 
> Luiz

Not everything that is in the device tree has to be used. It is a
description of the hardware, not a rigid set of instructions for what
the OS has to do. The OS still does whatever it wants based on that info.

You can ask anyone about this. See Thomas Petazzoni's slides as just one
example.
https://elinux.org/images/f/f9/Petazzoni-device-tree-dummies_0.pdf

| The Device Tree is really a hardware description language.
| It should describe the hardware layout, and how it works.
| But it should not describe which particular hardware configuration you’re interested in.
| As an example:
| You may describe in the DT whether a particular piece of hardware supports DMA or not.
| But you may not describe in the DT if you want to use DMA or not.

It's a really weak argument for recommending users to remove the compatible
string, thereby deliberately breaking ABI compatibility in one direction,
to literally _no_ benefit.

Compatible strings for MDIO controllers are, in essence, not strange.
They are independent devices which could reasonably be bound to their
own drivers. I don't see what's awkward about this.