Message-ID: <CAJq09z6iX9s75Y2G46V_CEMiAk2PSGW6fF4t4QSPbjEXgs1iTQ@mail.gmail.com>
Date:   Thu, 30 Jun 2022 14:05:39 -0300
From:   Luiz Angelo Daros de Luca <luizluca@...il.com>
To:     Alvin Šipraga <ALSI@...g-olufsen.dk>
Cc:     "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
        Arınç ÜNAL <arinc.unal@...nc9.com>
Subject: Re: [PATCH net-next RFC 0/3] net: dsa: realtek: drop custom slave MII

> Hi Luiz,
>
> On Wed, Jun 29, 2022 at 01:43:45PM -0300, Luiz Angelo Daros de Luca wrote:
> > This RFC patch series cleans realtek-smi custom slave mii bus. Since
> > fe7324b932, dsa generic code provides everything needed for
> > realtek-smi driver. For extra caution, this series should be applied
> > in two steps: the first 2 patches introduce the new code path that
> > uses dsa generic code. It will show a warning message if the tree
> > contains deprecated references. It will still fall back to the old
> > code path if an "mdio"
> > is not found.
>
> In principle I like your changes, but I'm not sure if what you are doing
> is allowed, since DT is ABI. The fact that you have to split this into
> two steps, with the first step warning about old "incompatible" DTs
> (your point 3 below) before the second step breaks that compatibility,
> suggests that you are aware that you could be breaking old DTs.

Thanks Alvin for your review. Yes, that is a good question for the ML.
I don't know at what level we can break compatibility (DT and driver).
That's why it is a RFC.

> I'm not going to argue with you if you say "but the node with compatible
> realtek,smi-mdio was also called mdio in the bindings, so it shouldn't
> break old DTs", which is a valid point. But if that is your rationale,
> then there's no need to split the series at all, right?

The DT requires "realtek,smi-mdio" but also mentions the "mdio" name,
not a generic name as "mdioX". If we agree that the name "mdio" is
already required by the DT bindings, it is the driver implementation
that is not compliant. Even if we are not violating the DT bindings,
we are changing the driver behavior. That's why I suggested the
transition process. I do believe that it would be very, very rare to
name that mdio as anything other than "mdio" and even the driver
itself is too fresh to be widespread. In a non-RFC series, I would
also drop the "realtek,smi-mdio" compatible string from the bindings
(as it is back compatible).

> If you want to avoid that debate, what you could do instead is add a
> const char *slave_mii_compatible; member to struct dsa_switch, and try
> searching in dsa_switch_setup() for a child node with that compatible if
> the lookup of a node named "mdio" fails. I don't know if this would help
> you do the same thing with other drivers.

The DSA change to accept "mdio" was an improvement to avoid adding a
custom slave mdio when you already have a single mdio and just need to
point to a DT node. Adding compatible strings for that situation does
not make much sense as a compatible string is not necessary when you
are already restricting your case to a single mdio. For more complex
setups, you still need to create your own slave mdio implementation.
Some drivers already depend on the "mdio" name and this series is also
a suggestion for them to try their drivers dropping their custom slave
mdio implementations.

> Btw, I think the first patch in the series is kind of pointless. You can
> just do the rename of ds_ops_mdio to ds_ops in the last patch, adding
> your justification in the commit message: "while we're at it, rename
> ds_ops_mdio etc...".

As a RFC, I'm trying to split each change in such a way they can be
merged individually. I believe that the new names make it clearer why
we have two structures. Even if the idea behind this series did not
get accepted, that first patch might be useful for someone reading the
driver for the first time.

Regards,

>
> Kind regards,
> Alvin
>
> >
> > >
> > > The last patch cleans all the deprecated code while keeping the kernel
> > > messages. However, if there is no "mdio" node but there is a node with
> > > the old compatible stings "realtek,smi-mdio", it will show an error. It
> > > should still work but it will use polling instead of interruptions.
> > >
> > > My idea, if accepted, is to submit patches 1 and 2 now. After a
> > > reasonable period, submit patch 3.
> > >
> > > I don't have an SMI-connected device and I'm asking for testers. It
> > > would be nice to test the first 2 patches with:
> > > 1) "mdio" without a compatible string. It should work without warnings.
> > > 2) "mdio" with a compatible string. It should work with a warning asking
> > > to remove the compatible string
> > > 3) "xxx" node with compatible string. It should work with a warning
> > > asking to rename "xxx" to "mdio" and remove the compatible string
> > >
> > > In all those cases, the switch should still keep using interruptions.
> > >
> > > After that, the last patch can be applied. The same tests can be
> > > performed:
> > > 1) "mdio" without a compatible string. It should work without warnings.
> > > 2) "mdio" with a compatible string. It should work with a warning asking
> > > to remove the compatible string
> > > 3) "xxx" node with compatible string. It should work with an error
> > > asking to rename "xxx" to "mdio" and remove the compatible string. The
> > > switch will use polling instead of interruptions.
> > >
> > > This series might inspire other drivers as well. Currently, most dsa
> > > driver implements a custom slave mii, normally only defining a
> > > phy_{read,write} and loading properties from an "mdio" OF node. Since
> > > fe7324b932, dsa generic code can do all that if the mdio node is named
> > > "mdio".  I believe most drivers could simply drop their slave mii
> > > implementations and add phy_{read,write} to the dsa_switch_ops. For
> > > drivers that look for an "mdio-like" node using a compatible string, it
> > > might need some type of transition to let vendors update their OF tree.
> > >
> > > Regards,
> > >
> > > Luiz
> > >
> >
> > I might have forgotten to add a new line after the subject. It ate the
> > first paragraph. I'm top-posting it.
> >
> > Regards,
> >
> > Luiz

Powered by blists - more mailing lists