[Linux-stm32] [PATCH] net: stmmac: Fix PTP ref clock for Tegra234

[Andrew Lunn]

On Mon, Jun 16, 2025 at 11:06:54AM +0100, Jon Hunter wrote:
> 
> On 13/06/2025 14:22, Andrew Lunn wrote:
> > > > So you can definitively say, PTP does actually work? You have ptp4l
> > > > running with older kernels and DT blob, and it has sync to a grand
> > > > master?
> > > 
> > > So no I can't say that and I have not done any testing with PTP to be clear.
> > > However, the problem I see, is that because the driver defines the name as
> > > 'ptp-ref', if we were to update both the device-tree and the driver now to
> > > use the expected name 'ptp_ref', then and older device-tree will no longer
> > > work with the new driver regardless of the PTP because the
> > > devm_clk_bulk_get() in tegra_mgbe_probe() will fail.
> > > 
> > > I guess we could check to see if 'ptp-ref' or 'ptp_ref' is present during
> > > the tegra_mgbe_probe() and then update the mgbe_clks array as necessary.
> > 
> > Lets just consider for the moment, that it never worked.
> 
> To be clear, by 'it never worked', you are referring to only PTP support?
> Then yes that is most likely.

Yes, i'm just referring to PTP. I would be very surprised if
sending/receiving Ethernet frames is broken, that gets lots of
testing.

> > If we change the device tree to the expected 'ptp_ref', some devices
> > actually start working. None regress, because none ever worked. We can
> > also get the DT change added to stable, so older devices start
> > working. We keep the code nice and clean, no special case.
> 
> Although PTP may not work, basic ethernet support does and 'correcting' the
> device-tree only, will break basic ethernet support for this device.

We clearly don't want to do that. But we should be able to come up
with a fix which does not make things worse. The obvious one is that
we have both ptp-ref and ptp_ref in tegra234.dtsi, so that both
mgbe_clks in dwmac-tegra.c and stmmac_probe_config_dt is happy.

	Andrew