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: <b54afc33-5863-4c8b-8d6d-24b4447631e1@nvidia.com>
Date: Wed, 25 Jun 2025 15:01:51 +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 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.
> 
> 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.
> 
> 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.

> If it does actually work, can we cause a regression by renaming the
> clock in DT? I _guess_ so, if the DT also has the clock wrong. So it
> is a fixed-clock, and that fixed clock has the wrong frequency set. It
> is not used at the moment, so being wrong does not matter. But when we
> start using it, things break. Is this possible? I don't know, i've not
> looked at the DT.
> 
> Before we decide how to fix this, we need a proper understanding of
> what is actually broken/works.

AFAIK we have never tested PTP with this driver on this device. So the 
risk of breaking something is low for this device.

Jon

-- 
nvpublic