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 ?