Re: [RFC PATCH net-next 1/5] net: dsa: realtek-smi: fix mdio_free bug on module unload
From: Vladimir Oltean <olteanv@gmail.com>
Date: 2021-08-22 23:11:08
Also in:
lkml, netdev
On Sun, Aug 22, 2021 at 10:42:23PM +0000, Alvin Šipraga wrote:
quoted
Objection: dsa_switch_teardown has: if (ds->slave_mii_bus && ds->ops->phy_read) mdiobus_unregister(ds->slave_mii_bus);This is unregistering an mdiobus registered in dsa_switch_setup: if (!ds->slave_mii_bus && ds->ops->phy_read) { ds->slave_mii_bus = devm_mdiobus_alloc(ds->dev); if (!ds->slave_mii_bus) { err = -ENOMEM; goto teardown; } dsa_slave_mii_bus_init(ds); err = mdiobus_register(ds->slave_mii_bus); if (err < 0) goto teardown; } However, we don't enter this codepath because: - ds->slave_mii_bus is already set in the call to ds->ops->setup() before the code snippet above; - ds->ops->phy_read is not set. We don't want to either, since we want to use of_mdiobus_register().quoted
The realtek_smi_setup_mdio function does: smi->ds->slave_mii_bus = smi->slave_mii_bus; so I would expect that this would result in a double unregister on some systems. I haven't went through your new driver, but I wonder whether you have the phy_read and phy_write methods implemented? Maybe that is the difference?Right, phy_read/phy_write are not set in the dsa_switch_ops of rtl8365mb. So we should be safe.
Correct, DSA only unregisters the ds->slave_mii_bus it has registered, which is provided when the driver implements phy_read and/or phy_write but does not set/register ds->slave_mii_bus itself. The patch is fine.
It did get me thinking that it would be nice if dsa_register_switch() could call of_mdiobus_register() when necessary, since the snippet above (and its call to dsa_slave_mii_bus_init()) is almost same as realtek_smi_setup_mdio(). It would simplify some logic in realtek-smi drivers and obviate the need for this patch. I am not sure what the right approach to this would be but with some pointers I can give it a shot.
I don't think DSA could call of_mdiobus_register, since you would need to pass it the OF node you want and the read/write ops for the bus and its name and a place to store it (one DSA switch might have more than one MDIO bus), and I just fail to see the point of doing that. The whole point of having ds->slave_mii_bus (either allocated by the driver or by DSA) is to access the PHY registers of a port under a very narrow set of assumptions: it implicitly assumes that the port N has a PHY at MDIO address N, as opposed to doing the usual which is to follow the phy-handle, and that there is a single internal MDIO bus. DSA will do this as last resort in dsa_slave_phy_setup. But if you use of_mdiobus_register, just put a phy-handle in the device tree and be done, you don't need ds->ops->phy_read or ds->ops->phy_write, nor can you/should you overload these pointers for DSA to do the of_mdiobus_register for you.
quoted
quoted
static enum dsa_tag_protocol rtl8366_get_tag_protocol(struct dsa_switch *ds, int port, enum dsa_tag_protocol mp)@@ -1505,6 +1512,7 @@ static int rtl8366rb_detect(struct realtek_smi *smi) static const struct dsa_switch_ops rtl8366rb_switch_ops = { .get_tag_protocol = rtl8366_get_tag_protocol, .setup = rtl8366rb_setup, + .teardown = rtl8366rb_teardown, .phylink_mac_link_up = rtl8366rb_mac_link_up, .phylink_mac_link_down = rtl8366rb_mac_link_down, .get_strings = rtl8366_get_strings, --2.32.0