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:
quoted
On Thu, Dec 04, 2025 at 10:58:40AM +0100, Paolo Abeni wrote:
quoted
On 11/29/25 4:07 AM, Rohan G Thomas wrote:
quoted
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 <redacted>
---
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/ (local)
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.
quoted
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!