[net-next,PATCH v2] enetc: Increase eMDIO MDC rate to 2.5 MHz

[net-next,PATCH v2] enetc: Increase eMDIO MDC rate to 2.5 MHz

[Marek Vasut]

The current eMDIO MDC rate is 558 kHz on i.MX95 B0. This is very low,
but also very compatible. However, for example NXP TJA1120 PHY needs
at minimum 1 MHz MDC clock and 558 kHz does not work with that PHY.

As a minimum change, increase the MDC clock to 2.5 MHz which matches
the 802.3 specification. Also, even old PHYs like LAN8210Ai, KSZ8794,
DP83822 support up to 2.5 MHz MDC clock frequency, and it covers the
NXP TJA1120 as well. There is no known rationale for why the 558 kHz
was picked when the eMDIO driver was added.

Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>
Cc: Clark Wang <xiaoning.wang@nxp.com>
Cc: Claudiu Manoil <claudiu.manoil@nxp.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Wei Fang <wei.fang@nxp.com>
Cc: imx@lists.linux.dev
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
---
V2: Use 2.5 MHz per 802.3 spec, update commit message
---
 drivers/net/ethernet/freescale/enetc/enetc_mdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
index 998aaa394e9c4..a90a04a47befd 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
@@ -24,7 +24,7 @@
 
 #define ENETC_EMDIO_CFG \
 	(MDIO_CFG_HOLD(2) | \
-	 MDIO_CFG_CLKDIV(258) | \
+	 MDIO_CFG_CLKDIV(66) | \
 	 MDIO_CFG_NEG)
 
 #define MDIO_CTL_DEV_ADDR(x)	((x) & 0x1f)
-- 
2.53.0

Re: [net-next,PATCH v2] enetc: Increase eMDIO MDC rate to 2.5 MHz

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 (1) · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The patch changes ENETC_EMDIO_CFG in
  drivers/net/ethernet/freescale/enetc/enetc_mdio.c from…

Pre-existing issues:
- [Medium] Documentation/devicetree/bindings/net/fsl,enetc-mdio.yaml
  covers pci1957,ee01 (LS1028A) and pci1131,ee00 (i.MX95/94).

--

enetc: Increase eMDIO MDC rate to 2.5 MHz

This commit changes the fixed eMDIO clock divider in ENETC_EMDIO_CFG from
258 to 66. The goal is to raise MDC from 558 kHz to 2.5 MHz on i.MX95 B0.
The NXP TJA1120 PHY needs an MDC of at least 1 MHz, which is the reason
for the change.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> index 998aaa394e9c4..a90a04a47befd 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> @@ -24,7 +24,7 @@
>  
>  #define ENETC_EMDIO_CFG \
>  	(MDIO_CFG_HOLD(2) | \
> -	 MDIO_CFG_CLKDIV(258) | \
> +	 MDIO_CFG_CLKDIV(66) | \
>  	 MDIO_CFG_NEG)

[Severity: Medium]
The commit message only describes i.MX95 B0. What MDC rate does this
divider give on the other SoCs that use it?

ENETC_EMDIO_CFG is a compile-time constant and does not depend on the
input clock. enetc_mdio_read_c22(), enetc_mdio_write_c22(),
enetc_mdio_read_c45() and enetc_mdio_write_c45() write it to MDIO_CFG
before every transaction:

    mdio_cfg = ENETC_EMDIO_CFG;
    ...
    enetc_mdio_wr(mdio_priv, ENETC_MDIO_CFG, mdio_cfg);

These accessors are installed by:

  - enetc_pci_mdio_probe(), for both the LS1028A EMDIO (1957:ee01) and
    the i.MX95/i.MX94 netc_emdio (1131:ee00)
  - enetc_mdio_probe() and enetc_imdio_create() in enetc_pf_common.c
  - vsc9959_mdio_bus_alloc(), for the LS1028A Felix switch internal MDIO
  - netc_port_create_emdio_bus(), for the NETC switch per-port EMDIO

The driver uses a different system clock for each of the two generations
in enetc.c:

    .sysclk_freq = ENETC_CLK_400M,  /* enetc_pf_data */
    .sysclk_freq = ENETC_CLK_333M,  /* enetc4_pf_data */

The sibling QorIQ driver, xgmac_mdio.c, puts its divider at the same bit
position and uses MDC = f_in / (2 * div + 1). Under that formula the new
divider gives f_in / 133.

If the LS1028A EMDIO is clocked at 400 MHz, would MDC be about 3.0 MHz?
The old divider gave about 774 kHz. That new rate is above the 2.5 MHz
802.3 limit the commit message is aiming for. Even at 333 MHz, the result
would be about 2.504 MHz, slightly over the limit.

The driver has no per-SoC divider and does not read the input clock rate.
Boards such as LS1028A RDB/QDS, Kontron sl28 or TQ MBLS1028A would have
no way to bring MDC back down.

Could the divider be derived from the actual input clock, or at least
chosen per SoC?

[Severity: Medium]
This is a pre-existing issue and was not introduced by this patch. The
binding and the driver do not agree on how the MDC rate is set.

Documentation/devicetree/bindings/net/fsl,enetc-mdio.yaml covers both
pci1957,ee01 and pci1131,ee00. It includes mdio.yaml, so the generic
clock-frequency property passes schema validation:

clock-frequency:
    description:
      Desired MDIO bus clock frequency in Hz. Values greater than IEEE 802.3
      defined 2.5MHz should only be used when all devices on the bus support
      the given clock speed.

enetc_pci_mdio_probe() never reads this property. It only calls:

    err = of_mdiobus_register(bus, dev->of_node);

The divider therefore always comes from ENETC_EMDIO_CFG, and any
clock-frequency value in the DT is silently ignored. By comparison,
xgmac_mdio_set_mdc_freq() in xgmac_mdio.c and fec_main.c both honour this
property.

This patch makes the fixed MDC about 3.9 times faster on every board.
Should the driver honour clock-frequency, so that a board whose PHY or
wiring can't handle the new rate can lower it through the DT?

That would also need the input clock rate. The netc_emdio and
enetc_mdio_pf3 DT nodes don't provide it today.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260924180607.60932-1-marex%40nabladev.com

Re: [net-next,PATCH v2] enetc: Increase eMDIO MDC rate to 2.5 MHz

[patchwork-bot+netdevbpf]

Hello:

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

On Thu, 24 Sep 2026 20:05:19 +0200 you wrote:
> The current eMDIO MDC rate is 558 kHz on i.MX95 B0. This is very low,
> but also very compatible. However, for example NXP TJA1120 PHY needs
> at minimum 1 MHz MDC clock and 558 kHz does not work with that PHY.
> 
> As a minimum change, increase the MDC clock to 2.5 MHz which matches
> the 802.3 specification. Also, even old PHYs like LAN8210Ai, KSZ8794,
> DP83822 support up to 2.5 MHz MDC clock frequency, and it covers the
> NXP TJA1120 as well. There is no known rationale for why the 558 kHz
> was picked when the eMDIO driver was added.
> 
> [...]

Here is the summary with links:
  - [net-next,v2] enetc: Increase eMDIO MDC rate to 2.5 MHz
    https://git.kernel.org/netdev/net-next/c/587acb86d646

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

Re: [net-next,PATCH v2] enetc: Increase eMDIO MDC rate to 2.5 MHz

[Marek Vasut]

On 9/30/26 4:10 AM, patchwork-bot+netdevbpf@kernel.org wrote:
> Hello:
> 
> This patch was applied to netdev/net-next.git (main)
> by Jakub Kicinski <kuba@kernel.org>:
> 
> On Thu, 24 Sep 2026 20:05:19 +0200 you wrote:
>> The current eMDIO MDC rate is 558 kHz on i.MX95 B0. This is very low,
>> but also very compatible. However, for example NXP TJA1120 PHY needs
>> at minimum 1 MHz MDC clock and 558 kHz does not work with that PHY.
>>
>> As a minimum change, increase the MDC clock to 2.5 MHz which matches
>> the 802.3 specification. Also, even old PHYs like LAN8210Ai, KSZ8794,
>> DP83822 support up to 2.5 MHz MDC clock frequency, and it covers the
>> NXP TJA1120 as well. There is no known rationale for why the 558 kHz
>> was picked when the eMDIO driver was added.
>>
>> [...]
> 
> Here is the summary with links:
>    - [net-next,v2] enetc: Increase eMDIO MDC rate to 2.5 MHz
>      https://git.kernel.org/netdev/net-next/c/587acb86d646
This should have likely been applied only after someone from NXP looked 
at it.

RE: [net-next,PATCH v2] enetc: Increase eMDIO MDC rate to 2.5 MHz

[Wei Fang]

Sorry, this email was missed because it did not match the filtering rules I set.

Hi Valdimir and Claudiu,

Please take a look at this patch, it may affect LS1028A and S32N7 platforms.

> The current eMDIO MDC rate is 558 kHz on i.MX95 B0. This is very low,

The system clock of i.MX95 NETC is 333MHz, AFAIU, the MDC rate should be
333/(2*258+1) = 644KHz. I'm confused that why you said the rate is 558KHz.

> but also very compatible. However, for example NXP TJA1120 PHY needs
> at minimum 1 MHz MDC clock and 558 kHz does not work with that PHY.

We previously used the TJA1120-SDBR daughter card to connect to the ENETC
interface (RGMII) of the i.MX95 19x19 EVK board. However, we did not encounter
any issues with MDIO access. Furthermore, I did not see a minimum MDC
frequency rate of 1MHz on the TJA1120 datasheet. I'm not sure if this is an errata
of TJA1120.

> 
> As a minimum change, increase the MDC clock to 2.5 MHz which matches

The prerequisite is that NETC system clock is 333MHz, so that you can get a
MDC clock rate of 2.5MHz (333/(2*66 + 1)). But unfortunately, not all NETC
versions have a 333MHz system clock. For example, LS1028A is 400MHz, so
the MDC rate will be 3MHz, which will be a problem.

> the 802.3 specification. Also, even old PHYs like LAN8210Ai, KSZ8794,
> DP83822 support up to 2.5 MHz MDC clock frequency, and it covers the
> NXP TJA1120 as well. There is no known rationale for why the 558 kHz
> was picked when the eMDIO driver was added.
> 

> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>
> Cc: Clark Wang <xiaoning.wang@nxp.com>
> Cc: Claudiu Manoil <claudiu.manoil@nxp.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> Cc: Wei Fang <wei.fang@nxp.com>
> Cc: imx@lists.linux.dev
> Cc: linux-kernel@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
> V2: Use 2.5 MHz per 802.3 spec, update commit message
> ---
>  drivers/net/ethernet/freescale/enetc/enetc_mdio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> index 998aaa394e9c4..a90a04a47befd 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> @@ -24,7 +24,7 @@
> 
>  #define ENETC_EMDIO_CFG \
>  	(MDIO_CFG_HOLD(2) | \
> -	 MDIO_CFG_CLKDIV(258) | \
> +	 MDIO_CFG_CLKDIV(66) | \
>  	 MDIO_CFG_NEG)
> 
>  #define MDIO_CTL_DEV_ADDR(x)	((x) & 0x1f)
> --
> 2.53.0

Re: [net-next,PATCH v2] enetc: Increase eMDIO MDC rate to 2.5 MHz

[Marek Vasut]

On 9/30/26 5:40 AM, Wei Fang wrote:
> Sorry, this email was missed because it did not match the filtering rules I set.

No worries.

> Hi Valdimir and Claudiu,
> 
> Please take a look at this patch, it may affect LS1028A and S32N7 platforms.
> 
>> The current eMDIO MDC rate is 558 kHz on i.MX95 B0. This is very low,
> 
> The system clock of i.MX95 NETC is 333MHz, AFAIU, the MDC rate should be
> 333/(2*258+1) = 644KHz. I'm confused that why you said the rate is 558KHz.

That is what I observe on a scope on local MX95 board (not the EVK).

>> but also very compatible. However, for example NXP TJA1120 PHY needs
>> at minimum 1 MHz MDC clock and 558 kHz does not work with that PHY.
> 
> We previously used the TJA1120-SDBR daughter card to connect to the ENETC
> interface (RGMII) of the i.MX95 19x19 EVK board. However, we did not encounter
> any issues with MDIO access.

Most PHYs are fine with the low frequency.

> Furthermore, I did not see a minimum MDC
> frequency rate of 1MHz on the TJA1120 datasheet. I'm not sure if this is an errata
> of TJA1120.

The TJA1120 RM is not public, but look at its predecessor:

https://www.nxp.com/docs/en/data-sheet/TJA1101B.pdf

Page 46 bottom
Table 37. Dynamic characteristics...continued
Tclk(MDC) MDC ... clock period ... Min 400 ns

400ns ~= 2.5 MHz .

>> As a minimum change, increase the MDC clock to 2.5 MHz which matches
> 
> The prerequisite is that NETC system clock is 333MHz, so that you can get a
> MDC clock rate of 2.5MHz (333/(2*66 + 1)). But unfortunately, not all NETC
> versions have a 333MHz system clock. For example, LS1028A is 400MHz, so
> the MDC rate will be 3MHz, which will be a problem.
Yes, this is my concern.

Are those clock which feed MDC clock available via clock framework on LS 
? If so, we could calculate the divider based on those clock.

RE: [net-next,PATCH v2] enetc: Increase eMDIO MDC rate to 2.5 MHz

[Wei Fang]

> >> The current eMDIO MDC rate is 558 kHz on i.MX95 B0. This is very low,
> >
> > The system clock of i.MX95 NETC is 333MHz, AFAIU, the MDC rate should
> > be
> > 333/(2*258+1) = 644KHz. I'm confused that why you said the rate is 558KHz.
>
> That is what I observe on a scope on local MX95 board (not the EVK).

Clark helped measure the MDC rate on the 95 EVK board this morning, and the
result was 644KHz, which is consistent with the theoretical value. The scope's
accuracy or other factors may be causing you to observe a rate of 558kHz. But
anyway, the description of 558kHz is indeed confusing because it does not match
the theoretical value.

>
> >> but also very compatible. However, for example NXP TJA1120 PHY needs
> >> at minimum 1 MHz MDC clock and 558 kHz does not work with that PHY.
> >
> > We previously used the TJA1120-SDBR daughter card to connect to the
> > ENETC interface (RGMII) of the i.MX95 19x19 EVK board. However, we did
> > not encounter any issues with MDIO access.
>
> Most PHYs are fine with the low frequency.

Yes, but the example you gave is TJA1120, and we also connected to TJA1120
without this problem, so this is what puzzles me.

>
> > Furthermore, I did not see a minimum MDC frequency rate of 1MHz on the
> > TJA1120 datasheet. I'm not sure if this is an errata of TJA1120.
>
> The TJA1120 RM is not public, but look at its predecessor:
>
> https://www.n/
> xp.com%2Fdocs%2Fen%2Fdata-sheet%2FTJA1101B.pdf&data=05%7C02%7Cw
> ei.fang%40nxp.com%7C44f566383a0e4f1fbf4208df1ea9fcb7%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C639263387581887659%7CUnknow
> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=e
> sOmbNzJ0qJ0z7CyZYHWCm5ihMjq%2BFT1AKfT6xT1RUc%3D&reserved=0
>
> Page 46 bottom
> Table 37. Dynamic characteristics...continued
> Tclk(MDC) MDC ... clock period ... Min 400 ns
>
> 400ns ~= 2.5 MHz .

Thanks, I find the similar context in TJA1120's datasheet. The max period is
1000ns, so the min rate is 1MHz. It's weird that we did not see any MDIO
access issues with TJA1120. I saw a note about MDC timing: "Not measured
in production, guaranteed by design." It's possible that the minimum of 1MHz
is a theoretical value, and it may actually work even below 1MHz.

>
> >> As a minimum change, increase the MDC clock to 2.5 MHz which matches
> >
> > The prerequisite is that NETC system clock is 333MHz, so that you can
> > get a MDC clock rate of 2.5MHz (333/(2*66 + 1)). But unfortunately,
> > not all NETC versions have a 333MHz system clock. For example, LS1028A
> > is 400MHz, so the MDC rate will be 3MHz, which will be a problem.
> Yes, this is my concern.
>
> Are those clock which feed MDC clock available via clock framework on LS ? If
> so, we could calculate the divider based on those clock.

No, we typically hardcode the clock frequency in the driver based on the NETC
version. Another simple method is to set the divisor to 166 instead of 66, which
will not cause any problems for using a 400MHz NETC.

Re: [net-next,PATCH v2] enetc: Increase eMDIO MDC rate to 2.5 MHz

[Andrew Lunn]

> No, we typically hardcode the clock frequency in the driver based on the NETC
> version. Another simple method is to set the divisor to 166 instead of 66, which
> will not cause any problems for using a 400MHz NETC.

There are use cases where you want the MDIO bus running at the 802.3
speed, or higher.

Some PHYs need firmware download because the OEM saved $0.02 by not
putting on an EEPROM. I've seen boards take 10s of seconds to download
the firmware on boot.

The Marvell PHYs allow you access to the raw TDR cable testing values,
which is a lot of data. Getting it faster allows nicer and more
responsive tools.

There might be an MDIO managed switch hanging off the MDIO bus, so
again, lots of traffic.

So please look at setting the divisor correctly to achieve 2.5Mhz, and
maybe consider implementing the device tree property:

  clock-frequency:
    description:
      Desired MDIO bus clock frequency in Hz. Values greater than IEEE 802.3
      defined 2.5MHz should only be used when all devices on the bus support
      the given clock speed.

so it can be overclocked.

   Andrew

Re: [net-next,PATCH v2] enetc: Increase eMDIO MDC rate to 2.5 MHz

[Marek Vasut]

On 9/30/26 8:12 AM, Wei Fang wrote:
>>>> The current eMDIO MDC rate is 558 kHz on i.MX95 B0. This is very low,
>>>
>>> The system clock of i.MX95 NETC is 333MHz, AFAIU, the MDC rate should
>>> be
>>> 333/(2*258+1) = 644KHz. I'm confused that why you said the rate is 558KHz.
>>
>> That is what I observe on a scope on local MX95 board (not the EVK).
> 
> Clark helped measure the MDC rate on the 95 EVK board this morning, and the
> result was 644KHz, which is consistent with the theoretical value. The scope's
> accuracy or other factors may be causing you to observe a rate of 558kHz.

That 644 kHz and 558 kHz differs too much to be an equipment 
miscalibration / misuse.

> But
> anyway, the description of 558kHz is indeed confusing because it does not match
> the theoretical value.

Do you know from which clock are the MDC clock derived from on MX95 ?

>>>> but also very compatible. However, for example NXP TJA1120 PHY needs
>>>> at minimum 1 MHz MDC clock and 558 kHz does not work with that PHY.
>>>
>>> We previously used the TJA1120-SDBR daughter card to connect to the
>>> ENETC interface (RGMII) of the i.MX95 19x19 EVK board. However, we did
>>> not encounter any issues with MDIO access.
>>
>> Most PHYs are fine with the low frequency.
> 
> Yes, but the example you gave is TJA1120, and we also connected to TJA1120
> without this problem, so this is what puzzles me.

[...]

>> Page 46 bottom
>> Table 37. Dynamic characteristics...continued
>> Tclk(MDC) MDC ... clock period ... Min 400 ns
>>
>> 400ns ~= 2.5 MHz .
> 
> Thanks, I find the similar context in TJA1120's datasheet. The max period is
> 1000ns, so the min rate is 1MHz. It's weird that we did not see any MDIO
> access issues with TJA1120. I saw a note about MDC timing: "Not measured
> in production, guaranteed by design." It's possible that the minimum of 1MHz
> is a theoretical value, and it may actually work even below 1MHz.

I got a report it is problematic, hence this patch. But maybe this is 
also related to the 558 kHz MDC clock I measure locally vs. 644 kHz MDC 
clock on your end.

>>>> As a minimum change, increase the MDC clock to 2.5 MHz which matches
>>>
>>> The prerequisite is that NETC system clock is 333MHz, so that you can
>>> get a MDC clock rate of 2.5MHz (333/(2*66 + 1)). But unfortunately,
>>> not all NETC versions have a 333MHz system clock. For example, LS1028A
>>> is 400MHz, so the MDC rate will be 3MHz, which will be a problem.
>> Yes, this is my concern.
>>
>> Are those clock which feed MDC clock available via clock framework on LS ? If
>> so, we could calculate the divider based on those clock.
> 
> No, we typically hardcode the clock frequency in the driver based on the NETC
> version. Another simple method is to set the divisor to 166 instead of 66, which
> will not cause any problems for using a 400MHz NETC.

Hmmmm, are those clock available on MX95 ? Maybe we can do some sort of 
fallback -- assume 166 MHz clock on LS, and obtain the clock and clock 
rate via clock framework on MX95 ?