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] [day] [month] [year] [list]

Message-ID: <f7ea5d79-4aff-4d8a-a966-5d77e2c60b51@nvidia.com>
Date: Thu, 26 Jun 2025 09:52:02 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Andrew Lunn <andrew@...n.ch>, Thierry Reding <treding@...dia.com>
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 25/06/2025 17:24, Andrew Lunn wrote:
>>> Now, lets consider the case some devices do actually work. How are
>>> they working? Must it be the fallback? The ptp-ref clock is actually
>>> turned on, and if the ptp-ref clock and the main clock tick at the
>>> same rate, ptp would work. I _guess_, if the main clock and the
>>> ptp-ref clock tick at different rates, you get something from the ptp
>>> hardware, but it probably does not get sync with a grand master, or if
>>> it does, the jitter is high etc. So in effect it is still broken.
>>>
>>> Can somebody with the datasheet actually determine where ptp-ref clock
>>> comes from? Is it just a gated main clock? Is it from a pin?
>>
>> Looking at the datasheet, this is a pin to the controller and sourced from
>> an external clock.
> 
> So the fallback of the main clock is not likely to help, unless by
> chance the external clock and the main clock happen to be the same
> frequency.

Actually the fallback to the main clock is not applicable here for this 
Tegra device because we don't have a clock called 'stmmaceth'. In fact, 
that is something else we should fix because for Tegra234, I see ...

  tegra-mgbe 6800000.ethernet: Cannot get CSR clock

However, this is expected because there is no 'stmmaceth'. The fallback 
to the main clock is only applicable to !snps,dwc-qos-ethernet-4.10 
devices but this should also be applicable to 'nvidia,tegra234-mgbe' as 
well.

>> AFAIK we have never tested PTP with this driver on this device. So the risk
>> of breaking something is low for this device.
> 
> So it seems like the simple fix is to list both ptp-ref and ptp_ref,
> pointing to the same clock, along with a comment explaining why you
> have this odd construction.
> 
> Please could you test that?

I am sure it will work and yes I can test. I am a bit concerned that the 
device-tree maintainers will not want this because strictly device-tree 
should describe the hardware and adding workarounds is not ideal. Don't 
get me wrong this is a massive oversight on our behalf to begin with. 
Ideally we would handle this somewhere in the dwmac-tegra.c driver.

Jon

-- 
nvpublic