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: <5a3e1026-740a-4829-bfd2-ce4c4525d2a0@lunn.ch>
Date: Fri, 13 Jun 2025 15:22:21 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jon Hunter <jonathanh@...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

> > 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?

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.

	Andrew