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.

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?

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.

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...".

Kind regards,
Alvin

quoted

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