netdev - Re: [PATCH] net: stmmac: Fix PTP ref clock for Tegra234

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <11d63030-1395-420a-9079-fe3cb672f468@nvidia.com>
Date: Wed, 25 Jun 2025 15:40:14 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Subbaraya Sundeep <sbhatta@...vell.com>,
 Andrew Lunn <andrew+netdev@...n.ch>, "David S . Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>, netdev@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com, linux-tegra@...r.kernel.org,
 Alexis Lothorrr <alexis.lothore@...tlin.com>
Subject: Re: [PATCH] net: stmmac: Fix PTP ref clock for Tegra234


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