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

[Jon Hunter]

On 16/06/2025 14:06, Andrew Lunn wrote:
> 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.

Yes that's a possibility. OK I will have a think about this some more.

Jon

-- 
nvpublic