With support for Ethernet PHY LEDs having been added, while
unregistering a MDIO bus and its child device liks PHYs there may be
"late" accesses to the MDIO bus. One typical use case is setting the PHY
LEDs brightness to OFF for instance.

We need to ensure that the MDIO bus controller remains entirely
functional since it runs off the main GENET adapter clock.

Link: https://lore.kernel.org/all/20230617155500.4005881-1-andrew@lunn.ch/
Fixes: 9a4e79697009 ("net: bcmgenet: utilize generic Broadcom UniMAC MDIO controller driver")
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
 drivers/net/ethernet/broadcom/genet/bcmmii.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index be042905ada2..c1d670c92958 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -668,5 +668,7 @@ void bcmgenet_mii_exit(struct net_device *dev)
 	if (of_phy_is_fixed_link(dn))
 		of_phy_deregister_fixed_link(dn);
 	of_node_put(priv->phy_dn);
+	clk_prepare_enable(priv->clk);
 	platform_device_unregister(priv->mii_pdev);
+	clk_disable_unprepare(priv->clk);
 }
-- 
2.34.1

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Thu, 22 Jun 2023 03:31:07 -0700 you wrote:
> With support for Ethernet PHY LEDs having been added, while
> unregistering a MDIO bus and its child device liks PHYs there may be
> "late" accesses to the MDIO bus. One typical use case is setting the PHY
> LEDs brightness to OFF for instance.
> 
> We need to ensure that the MDIO bus controller remains entirely
> functional since it runs off the main GENET adapter clock.
> 
> [...]

Here is the summary with links:
  - [net] net: bcmgenet: Ensure MDIO unregistration has clocks enabled
    https://git.kernel.org/netdev/net/c/1b5ea7ffb7a3

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

On Thu, Jun 22, 2023 at 03:31:07AM -0700, Florian Fainelli wrote:
> With support for Ethernet PHY LEDs having been added, while
> unregistering a MDIO bus and its child device liks PHYs there may be
> "late" accesses to the MDIO bus. One typical use case is setting the PHY
> LEDs brightness to OFF for instance.
> 
> We need to ensure that the MDIO bus controller remains entirely
> functional since it runs off the main GENET adapter clock.

So this clock is enabled in bcmgenet_open() and disabled in
bcmgenet_close(). The assumption being, the MDIO bus is only used when
the interface is up.

How does this work when there is an MDIO based switch attached? I had
similar problems with the FEC and mv88e6xxx. DSA would try to talk to
the switch with the master interface down, and MDIO would time out. I
needed to add runtime PM support to the MDIO bus ops.

       Andrew

On 6/22/2023 4:36 PM, Andrew Lunn wrote:
> On Thu, Jun 22, 2023 at 03:31:07AM -0700, Florian Fainelli wrote:
>> With support for Ethernet PHY LEDs having been added, while
>> unregistering a MDIO bus and its child device liks PHYs there may be
>> "late" accesses to the MDIO bus. One typical use case is setting the PHY
>> LEDs brightness to OFF for instance.
>>
>> We need to ensure that the MDIO bus controller remains entirely
>> functional since it runs off the main GENET adapter clock.
> 
> So this clock is enabled in bcmgenet_open() and disabled in
> bcmgenet_close(). The assumption being, the MDIO bus is only used when
> the interface is up.
> 
> How does this work when there is an MDIO based switch attached? I had
> similar problems with the FEC and mv88e6xxx. DSA would try to talk to
> the switch with the master interface down, and MDIO would time out. I
> needed to add runtime PM support to the MDIO bus ops.

We do not have that configuration to support today, and given the way 
that we do register the MDIO bus, it could actually be a bit challenging 
to support DSA here, I might still have a board around to test, one day.

Passing the clock to the MDIO driver does require quite a bit of 
restructuring in the driver such that the clock is only acquired around 
mii_bus::write and read operations, otherwise the clock remains 
constantly enabled, even if the network device is brought down, which 
burns power unnecessarily.

Since this is a fix, I went with the more targeted approach here.
-- 
Florian

> Since this is a fix, I went with the more targeted approach here.

Yes, this is fine for stable.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew