Re: [PATCH 2/4] dt-bindings: net: dsa: document internal MDIO bus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > [1] ...this. The SMI-controlled and MDIO-controlled Realtek switches are
> > otherwise the same, right? So why would they have different dt-bindings?
>
> Honestly, I'm wondering the answer to this as well. For some reason, when
> probing the SMI controlled Realtek switches, instead of just letting
> dsa_switch_setup() populate ds->slave_mii_bus, on realtek_smi_setup_mdio()
> on realtek-smi.c:
>
> - priv->slave_mii_bus is allocated.
> - mdio_np = of_get_compatible_child(priv->dev->of_node, "realtek,smi-mdio");
> - priv->slave_mii_bus->dev.of_node = mdio_np;
> - ds->slave_mii_bus = priv->slave_mii_bus;

I might be able to help here. The Realtek SMI version created a custom
slave_mii driver because it was the only way to associate it with an
MDIO DT node. And that DT node was required to specify the interrupts
for each phy0.
It would work without that mdio node, letting DSA setup handle the
slave bus, but it would rely only on polling for port status.

As we only have a single internal MDIO, the compatible string
"realtek,smi-mdio" would not be necessary if the driver checks for a
"mdio"-named child node. Maybe the code was just inspired by another
DSA driver that uses more MDIO buses or external ones. The "mdio" name
is suggested by docs since it was committed
(https://www.kernel.org/doc/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt).
That name was also kept in the YAML translation
(https://www.kernel.org/doc/Documentation/devicetree/bindings/net/dsa/realtek.yaml).

The Realtek MDIO driver was merged at the same release that included
the change that allows dsa_switch_setup() to reference the "mdio"
OF-node if present. That way, it could avoid creating a custom
slave_mii_bus driver.

I submitted a small series of patches to unify that behavior between
those two drivers:

https://lore.kernel.org/netdev/CAJq09z44SNGFkCi_BCpQ+3DuXhKfGVsMubRYE7AezJsGGOboVA@xxxxxxxxxxxxxx/
(This is my answer to the series opening message to include the first
paragraph ate by the editor)

There was some discussion but not NAC, ACK or RFC. It would have
dropped some lines of code. I can revive it if there is interest.

Regards,

Luiz



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux