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: <e87b4398-41de-4584-87fe-b9ad1df32dbe@lunn.ch>
Date: Mon, 16 Jun 2025 15:06:03 +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

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.

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ