linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net v2] net: mdio: mdio-bcm-unimac: Correct rate fallback logic
@ 2025-07-30 20:25 Florian Fainelli
  2025-07-30 21:01 ` Andrew Lunn
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Florian Fainelli @ 2025-07-30 20:25 UTC (permalink / raw)
  To: netdev
  Cc: Florian Fainelli, Doug Berger, Florian Fainelli,
	Broadcom internal kernel review list, Andrew Lunn,
	Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Jacob Keller, open list

When the parent clock is a gated clock which has multiple parents, the
clock provider (clk-scmi typically) might return a rate of 0 since there
is not one of those particular parent clocks that should be chosen for
returning a rate. Prior to ee975351cf0c ("net: mdio: mdio-bcm-unimac:
Manage clock around I/O accesses"), we would not always be passing a
clock reference depending upon how mdio-bcm-unimac was instantiated. In
that case, we would take the fallback path where the rate is hard coded
to 250MHz.

Make sure that we still fallback to using a fixed rate for the divider
calculation, otherwise we simply ignore the desired MDIO bus clock
frequency which can prevent us from interfacing with Ethernet PHYs
properly.

Fixes: ee975351cf0c ("net: mdio: mdio-bcm-unimac: Manage clock around I/O accesses")
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
Changes in v2:

- provide additional details as to how a parent clock can have a rate of
  0 (Andrew)

- incorporate Simon's feedback that an optional clock is NULL and
  therefore returns a rate of 0 as well

 drivers/net/mdio/mdio-bcm-unimac.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/mdio/mdio-bcm-unimac.c b/drivers/net/mdio/mdio-bcm-unimac.c
index b6e30bdf5325..7baab230008a 100644
--- a/drivers/net/mdio/mdio-bcm-unimac.c
+++ b/drivers/net/mdio/mdio-bcm-unimac.c
@@ -209,10 +209,9 @@ static int unimac_mdio_clk_set(struct unimac_mdio_priv *priv)
 	if (ret)
 		return ret;
 
-	if (!priv->clk)
+	rate = clk_get_rate(priv->clk);
+	if (!rate)
 		rate = 250000000;
-	else
-		rate = clk_get_rate(priv->clk);
 
 	div = (rate / (2 * priv->clk_freq)) - 1;
 	if (div & ~MDIO_CLK_DIV_MASK) {
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH net v2] net: mdio: mdio-bcm-unimac: Correct rate fallback logic
  2025-07-30 20:25 [PATCH net v2] net: mdio: mdio-bcm-unimac: Correct rate fallback logic Florian Fainelli
@ 2025-07-30 21:01 ` Andrew Lunn
  2025-07-31 20:21 ` Simon Horman
  2025-08-02  0:14 ` patchwork-bot+netdevbpf
  2 siblings, 0 replies; 4+ messages in thread
From: Andrew Lunn @ 2025-07-30 21:01 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: netdev, Doug Berger, Florian Fainelli,
	Broadcom internal kernel review list, Heiner Kallweit,
	Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Jacob Keller, open list

On Wed, Jul 30, 2025 at 01:25:33PM -0700, Florian Fainelli wrote:
> When the parent clock is a gated clock which has multiple parents, the
> clock provider (clk-scmi typically) might return a rate of 0 since there
> is not one of those particular parent clocks that should be chosen for
> returning a rate. Prior to ee975351cf0c ("net: mdio: mdio-bcm-unimac:
> Manage clock around I/O accesses"), we would not always be passing a
> clock reference depending upon how mdio-bcm-unimac was instantiated. In
> that case, we would take the fallback path where the rate is hard coded
> to 250MHz.
> 
> Make sure that we still fallback to using a fixed rate for the divider
> calculation, otherwise we simply ignore the desired MDIO bus clock
> frequency which can prevent us from interfacing with Ethernet PHYs
> properly.
> 
> Fixes: ee975351cf0c ("net: mdio: mdio-bcm-unimac: Manage clock around I/O accesses")
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>

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

    Andrew

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH net v2] net: mdio: mdio-bcm-unimac: Correct rate fallback logic
  2025-07-30 20:25 [PATCH net v2] net: mdio: mdio-bcm-unimac: Correct rate fallback logic Florian Fainelli
  2025-07-30 21:01 ` Andrew Lunn
@ 2025-07-31 20:21 ` Simon Horman
  2025-08-02  0:14 ` patchwork-bot+netdevbpf
  2 siblings, 0 replies; 4+ messages in thread
From: Simon Horman @ 2025-07-31 20:21 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: netdev, Doug Berger, Florian Fainelli,
	Broadcom internal kernel review list, Andrew Lunn,
	Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Jacob Keller, open list

On Wed, Jul 30, 2025 at 01:25:33PM -0700, Florian Fainelli wrote:
> When the parent clock is a gated clock which has multiple parents, the
> clock provider (clk-scmi typically) might return a rate of 0 since there
> is not one of those particular parent clocks that should be chosen for
> returning a rate. Prior to ee975351cf0c ("net: mdio: mdio-bcm-unimac:
> Manage clock around I/O accesses"), we would not always be passing a
> clock reference depending upon how mdio-bcm-unimac was instantiated. In
> that case, we would take the fallback path where the rate is hard coded
> to 250MHz.
> 
> Make sure that we still fallback to using a fixed rate for the divider
> calculation, otherwise we simply ignore the desired MDIO bus clock
> frequency which can prevent us from interfacing with Ethernet PHYs
> properly.
> 
> Fixes: ee975351cf0c ("net: mdio: mdio-bcm-unimac: Manage clock around I/O accesses")
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
> ---
> Changes in v2:
> 
> - provide additional details as to how a parent clock can have a rate of
>   0 (Andrew)
> 
> - incorporate Simon's feedback that an optional clock is NULL and
>   therefore returns a rate of 0 as well

Thanks for the update.

Reviewed-by: Simon Horman <horms@kernel.org>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH net v2] net: mdio: mdio-bcm-unimac: Correct rate fallback logic
  2025-07-30 20:25 [PATCH net v2] net: mdio: mdio-bcm-unimac: Correct rate fallback logic Florian Fainelli
  2025-07-30 21:01 ` Andrew Lunn
  2025-07-31 20:21 ` Simon Horman
@ 2025-08-02  0:14 ` patchwork-bot+netdevbpf
  2 siblings, 0 replies; 4+ messages in thread
From: patchwork-bot+netdevbpf @ 2025-08-02  0:14 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: netdev, opendmb, f.fainelli, bcm-kernel-feedback-list, andrew,
	hkallweit1, linux, davem, edumazet, kuba, pabeni, jacob.e.keller,
	linux-kernel

Hello:

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

On Wed, 30 Jul 2025 13:25:33 -0700 you wrote:
> When the parent clock is a gated clock which has multiple parents, the
> clock provider (clk-scmi typically) might return a rate of 0 since there
> is not one of those particular parent clocks that should be chosen for
> returning a rate. Prior to ee975351cf0c ("net: mdio: mdio-bcm-unimac:
> Manage clock around I/O accesses"), we would not always be passing a
> clock reference depending upon how mdio-bcm-unimac was instantiated. In
> that case, we would take the fallback path where the rate is hard coded
> to 250MHz.
> 
> [...]

Here is the summary with links:
  - [net,v2] net: mdio: mdio-bcm-unimac: Correct rate fallback logic
    https://git.kernel.org/netdev/net/c/a81649a4efd3

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



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-08-02  0:13 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-30 20:25 [PATCH net v2] net: mdio: mdio-bcm-unimac: Correct rate fallback logic Florian Fainelli
2025-07-30 21:01 ` Andrew Lunn
2025-07-31 20:21 ` Simon Horman
2025-08-02  0:14 ` patchwork-bot+netdevbpf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).