[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

[Jakub Kicinski]

On Wed, 30 Sep 2026 04:21:19 +0200 Marek Vasut wrote:
> 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.

Maybe say that in the commit message next time.

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

[Wei Fang]

> > 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:

Yeah, you are right, using clock-frequency is more flexible. We should add 
lock-frequency support later, so that a suitable divisor can be calculated
based on the current NETC system clock rate. Thanks.

> 
>   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 ?

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

[Wei Fang]

> > 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 ?

See below for details.

> >>> 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 ?

The MDC clock is derived from the NETC system clock. For iMX platforms, the
system clock is controlled by system manager (M33 core), Linux cannot
configure it. Moreover, the actual situation is a bit complicated. For iMX95, the
system clock source provided by the SoC to NETC is IMX95_CLK_ENET, which is
666MHz. There is a 1/2 divisor in NETCMIX, so the clock input to NETC is 333MHz.
Therefore, to obtain the actual system clock from the clock framework, we need
to add a fixed-factor clock to the DTS as the NETC's system clock. Some platforms
do not have this divisor. So we do not add the system clock to the binding-doc of
both emdio and enetc.

In addition, the NETC is also used on S32 platforms, that might be another story
altogether.

Therefore, hardcoding the clock frequency according to the NETC revision in
the driver is a simple and quick method, just like we did in the enetc driver.
https://elixir.bootlin.com/linux/v7.3-rc5/source/drivers/net/ethernet/freescale/enetc/enetc.c#L3770

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

[Marek Vasut]

On 10/1/26 2:45 AM, Wei Fang wrote:

Hello Wei,

>> 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 ?
> 
> The MDC clock is derived from the NETC system clock. For iMX platforms, the
> system clock is controlled by system manager (M33 core), Linux cannot
> configure it.

That is probably still fine, as long as the clock are available via SCMI 
and their clock frequency can be read (not written/set), we can use them.

> Moreover, the actual situation is a bit complicated. For iMX95, the
> system clock source provided by the SoC to NETC is IMX95_CLK_ENET, which is
> 666MHz. There is a 1/2 divisor in NETCMIX, so the clock input to NETC is 333MHz.
> Therefore, to obtain the actual system clock from the clock framework, we need
> to add a fixed-factor clock to the DTS as the NETC's system clock. Some platforms
> do not have this divisor. So we do not add the system clock to the binding-doc of
> both emdio and enetc.

This is something which can still be handled by a compatible string match.

> In addition, the NETC is also used on S32 platforms, that might be another story
> altogether.
> 
> Therefore, hardcoding the clock frequency according to the NETC revision in
> the driver is a simple and quick method, just like we did in the enetc driver.
> https://elixir.bootlin.com/linux/v7.3-rc5/source/drivers/net/ethernet/freescale/enetc/enetc.c#L3770

Let me try something better, give me a day or two.

Jakub, do you want a revert of this one, fix, or follow up patch ?

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

[Wei Fang]

> >> 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 ?
> >
> > The MDC clock is derived from the NETC system clock. For iMX platforms, the
> > system clock is controlled by system manager (M33 core), Linux cannot
> > configure it.
>
> That is probably still fine, as long as the clock are available via SCMI
> and their clock frequency can be read (not written/set), we can use them.

Yes, SCMI can read the clock frequency. However, because some platforms
have a divisor between the clock source and NETC, we also need special
handling in DTS - for example, a fixed-factor-clock. In addition, some
platforms do not expose a clock provider at all (e.g. LS1028A, and likely
S32N7), so they would require adding a fixed-clock in DTS.

All of these extra DTS modifications exist solely to obtain the clock
frequency - yet for a given NETC version, that frequency is effectively
a constant. Whether we put it in a fixed-clock/fixed-factor-clock in DTS
or in the driver, we are hard-coding the same constant; the only
difference is where it lives.

For these reasons, I believe hard-coding the per-version frequency
in the driver is the simpler and more efficient approach, rather than
introducing this extra DTS complexity just to read a constant.

>
> > Moreover, the actual situation is a bit complicated. For iMX95, the
> > system clock source provided by the SoC to NETC is IMX95_CLK_ENET, which
> is
> > 666MHz. There is a 1/2 divisor in NETCMIX, so the clock input to NETC is
> 333MHz.
> > Therefore, to obtain the actual system clock from the clock framework, we
> need
> > to add a fixed-factor clock to the DTS as the NETC's system clock. Some
> platforms
> > do not have this divisor. So we do not add the system clock to the
> binding-doc of
> > both emdio and enetc.
>
> This is something which can still be handled by a compatible string match.
>
> > In addition, the NETC is also used on S32 platforms, that might be another
> story
> > altogether.
> >
> > Therefore, hardcoding the clock frequency according to the NETC revision in
> > the driver is a simple and quick method, just like we did in the enetc driver.
> >
> https://elixir.bo/
> otlin.com%2Flinux%2Fv7.3-rc5%2Fsource%2Fdrivers%2Fnet%2Fethernet%2Ffr
> eescale%2Fenetc%2Fenetc.c%23L3770&data=05%7C02%7Cwei.fang%40nxp.c
> om%7C5cf4fb9826954a20a0bf08df1f5c1ab2%7C686ea1d3bc2b4c6fa92cd99c
> 5c301635%7C0%7C0%7C639264152594829487%7CUnknown%7CTWFpbGZs
> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk
> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=C8sTNGPtiqsUqz
> 1eXYif8deaG1R1e%2BEjcpzGHnkR16k%3D&reserved=0
>
> Let me try something better, give me a day or two.

Okay, but please consider Andrew's suggestion. Add clock-frequency
support for greater flexibility in adapting to different situations,
instead of fixing the MDC clock to 2.5MHz.

BTW, I'm currently OOO until next Thursday, so I won't be able to
reply to emails during that time. Sorry.

>
> Jakub, do you want a revert of this one, fix, or follow up patch ?

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

[Andrew Lunn]

> Okay, but please consider Andrew's suggestion. Add clock-frequency
> support for greater flexibility in adapting to different situations,
> instead of fixing the MDC clock to 2.5MHz.

I consider this nice to have. And to actually implement it, you need
to know the base frequency in order to calculate the divider. So i
suggest the first patches in the patchset set the clock to 2.5Mhz,
then consider other DT requested frequencies.

	 Andrew

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

[Marek Vasut]

On 9/30/26 3:27 PM, Marek Vasut wrote:

Hello again,

>> 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.

For the sake of completeness, the MX95 B0 I have on my desk now prints 
this in SM:

 >$ clock.r
...
097: busnetcmix           =  on,  133333333Hz
098: enet                 =  on,  666666666Hz
099: enetphytest200m      =  on,   24000000Hz
100: enetphytest500m      =  on,   24000000Hz
101: enetphytest667m      =  on,   24000000Hz
102: enetref              =  on,  250000000Hz
103: enettimer1           =  on,   24000000Hz

And the cycle time of MDC is 1.8ms , which is some 550 kHz .