linux-kernel - Re: [PATCH net v2] net: stmmac: Fix E2E delay mechanism

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: <aTgdlykiar3SlNox@shell.armlinux.org.uk>
Date: Tue, 9 Dec 2025 13:01:11 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: "G Thomas, Rohan" <rohan.g.thomas@...era.com>
Cc: Paolo Abeni <pabeni@...hat.com>, Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Richard Cochran <richardcochran@...il.com>,
	Jose Abreu <Jose.Abreu@...opsys.com>,
	Fugang Duan <fugang.duan@....com>,
	Kurt Kanzenbach <kurt@...utronix.de>, netdev@...r.kernel.org,
	linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v2] net: stmmac: Fix E2E delay mechanism

On Tue, Dec 09, 2025 at 06:01:05PM +0530, G Thomas, Rohan wrote:
> Hi Russell,
> 
> Thanks for reviewing the patch.
> 
> On 12/4/2025 4:49 PM, Russell King (Oracle) wrote:
> > On Thu, Dec 04, 2025 at 10:58:40AM +0100, Paolo Abeni wrote:
> > > On 11/29/25 4:07 AM, Rohan G Thomas wrote:
> > > > For E2E delay mechanism, "received DELAY_REQ without timestamp" error
> > > > messages show up for dwmac v3.70+ and dwxgmac IPs.
> > > > 
> > > > This issue affects socfpga platforms, Agilex7 (dwmac 3.70) and
> > > > Agilex5 (dwxgmac). According to the databook, to enable timestamping
> > > > for all events, the SNAPTYPSEL bits in the MAC_Timestamp_Control
> > > > register must be set to 2'b01, and the TSEVNTENA bit must be cleared
> > > > to 0'b0.
> > > > 
> > > > Commit 3cb958027cb8 ("net: stmmac: Fix E2E delay mechanism") already
> > > > addresses this problem for all dwmacs above version v4.10. However,
> > > > same holds true for v3.70 and above, as well as for dwxgmac. Updates
> > > > the check accordingly.
> > > > 
> > > > Fixes: 14f347334bf2 ("net: stmmac: Correctly take timestamp for PTPv2")
> > > > Fixes: f2fb6b6275eb ("net: stmmac: enable timestamp snapshot for required PTP packets in dwmac v5.10a")
> > > > Fixes: 3cb958027cb8 ("net: stmmac: Fix E2E delay mechanism")
> > > > Signed-off-by: Rohan G Thomas <rohan.g.thomas@...era.com>
> > > > ---
> > > > v1 -> v2:
> > > >     - Rebased patch to net tree
> > > >     - Replace core_type with has_xgmac
> > > >     - Nit changes in the commit message
> > > >     - Link: https://lore.kernel.org/all/20251125-ext-ptp-fix-v1-1-83f9f069cb36@altera.com/
> > > 
> > > Given there is some uncertain WRT the exact oldest version to be used,
> > > it would be great to have some 3rd party testing/feedback on this. Let's
> > > wait a little more.
> > 
> > As I said, in the v3.74 documentation, it is stated that the SNAPTYPSEL
> > functions changed between v3.50 and v3.60, so I think it would be better
> > to propose a patch to test for < v3.6.
> > 
> 
> I tested this on socfpga platforms like Agilex7 which are using
> 3.7x, but don't have any platforms with dwmac <= v3.6.
> 
> > Alternatively, if someone has the pre-v3.6 databook to check what the
> > SNAPTYPSEL definition is and compare it with the v3.6+ definition, that
> > would also be a good thing to do.
> > 
> >  From the 3.74:
> > 
> > SNAPTYPSEL
> > 00		?
> > 01		?
> > 10		Sync, Delay_Req
> > 11		Sync, PDelay_Req, PDelay_Resp
> > 
> > TSEVNTENA
> > 0		All messages except Announce, Management and Signalling
> > 1		Sync, Delay_Req, PDelay_Req, PDelay_Resp
> > 
> > No table is provided, so it's difficult to know what all the bit
> > combinations do for v3.74.
> 
> In 3.73a databook, Table 6-70 has the following information and this is
> similar to v5.1 and v5.3. But don't have 3.74 databook.
> 
> SNAPTYPSEL	TSMSTRENA	TSEVNTENA	PTP Messages
> 00		X 		0 		SYNC, Follow_Up,
> 						Delay_Req, Delay_Resp
> 00 		0 		1 		SYNC
> 00 		1 		1 		Delay_Req
> 01 		X 		0 		SYNC, Follow_Up,
> 						Delay_Req, Delay_Resp,
> 						Pdelay_Req, Pdelay_Resp,
> 						Pdelay_Resp_Follow_Up
> 01 		0 		1 		SYNC, Pdelay_Req,
> 						Pdelay_Resp
> 01 		1 		1 		Delay_Req, Pdelay_Req,
> 						Pdelay_Resp
> 10 		X 		X 		SYNC, Delay_Req
> 11 		X 		X 		Pdelay_Req, Pdelay_Resp

I can't fathom why they would use this table in v3.73a, then put
something different in v4.2, and then go back to this table in
v5.1, so I'm wondering whether any of these tables can be relied
upon. This seems to be a complete mess.

I think the only way out of this is to test this - and I wonder
whether stmmac_selftests.c could have tests added to check which
PTP messages and in which direction get timestamped in each of
these modes.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!