From: Simon Horman <horms@kernel.org>
To: "Jesper L. Nielsen" <jln@pascal-audio.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Richard Cochran <richardcochran@gmail.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Martin Kaistra <martin.kaistra@linutronix.de>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Siddharth Vadapalli <s-vadapalli@ti.com>,
Roger Quadros <rogerq@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2] net: ethernet: ti: am65-cpts: keep port and direction when matching PTPv1 TX timestamps
Date: Fri, 6 Nov 2026 11:58:02 +0000 [thread overview]
Message-ID: <20261106115802.GG865646@horms.kernel.org> (raw)
In-Reply-To: <20261103-am65-cpts-ptpv1-v2-1-e1f79ed1ba60@pascal-audio.com>
On Tue, Nov 03, 2026 at 09:42:52AM +0100, Jesper L. Nielsen wrote:
> The CPTS reports the message type of a timestamp event using the PTPv2
> header layout, i.e. the low nibble of the first header byte. In a PTPv1
> header that byte is the upper byte of versionPTP and always 0, so every
> PTPv1 event is reported as message type 0, while
> am65_skb_get_mtype_seqid() reads the PTPv1 message type from the control
> field. To make PTPv1 match at all, commit 1b9e743e923b ("net: ethernet:
> ti: am65-cpts: Fix PTPv1 message type on TX packets") overwrites the
> whole value compared against the skb with the skb's own value once the
> sequence ids are equal. That throws away the event type and the port
> number of the event as well, so a PTPv1 skb matches any TX event with
> the same sequence id on either port. For PTPv1 this defeats
> commit a23c657e332f ("net: ethernet: ti: am65-cpsw: Use also port
> number to identify timestamps"). The overwritten value also sticks for
> the rest of the TX queue walk.
>
> Since every PTPv1 frame reads as message type 0, the hardware timestamps
> all PTPv1 frames to UDP ports 319 and 320, including Follow_Up and
> Delay_Resp, for which no skb waits. With a PTPv1 master on both ports
> whose sequence ids run in step (e.g. a Dante device with primary and
> secondary network started at the same time), the unclaimed TX event of
> Follow_Up N on one port is still on the event list when the other port
> queues Sync N, and am65_cpts_find_tx_ts() tries to match before it
> checks for expiry. Sync N then gets the transmit time of the other
> port's Follow_Up N, and the master announces a preciseOriginTimestamp up
> to one Sync interval early to every slave on that network.
>
> For PTPv1 replace only the message type of the event with the skb's and
> keep its event type, port number and sequence id, and compute the value
> per skb.
>
> Tested on AM62x with ti-linux-6.12.y and the port number commit backported:
> without this patch every boot in which both ports started PTP together
> (10 of 10) sent wrong Sync timestamps, with it none did (0 of 29).
>
> The bug was tracked down, and this fix and changelog drafted, with the
> help of an AI coding assistant (Claude). I reviewed and tested it on
> hardware as described above.
>
> Fixes: a23c657e332f ("net: ethernet: ti: am65-cpsw: Use also port number to identify timestamps")
> Signed-off-by: Jesper L. Nielsen <jln@pascal-audio.com>
> Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> ---
> Changes in v2:
> - Wrap the commit a23c657e332f reference like the one above it (Siddharth)
> - Use netdev comment style for the new comment (Siddharth)
> - Collect Reviewed-by from Siddharth
> - Link to v1: https://patch.msgid.link/20261030-am65-cpts-ptpv1-v1-1-0bb4c370d970@pascal-audio.com
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2026-11-06 11:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 8:42 [PATCH net v2] net: ethernet: ti: am65-cpts: keep port and direction when matching PTPv1 TX timestamps Jesper L. Nielsen
2026-11-03 8:42 ` Jesper L. Nielsen via B4 Relay
2026-11-06 11:58 ` Simon Horman [this message]
2026-11-06 22:50 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261106115802.GG865646@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=jln@pascal-audio.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.kaistra@linutronix.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=rogerq@kernel.org \
--cc=s-vadapalli@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.