Re: [PATCH net-next v2 2/2] net: dsa: mv88e6xxx: embedded PTP timestamp support

[Vladimir Oltean]

On Fri, Jul 10, 2026 at 04:43:42PM +1000, Luke Howard wrote:
> @@ -6370,6 +6371,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
>  		.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
>  		.ptp_support = true,
>  		.ops = &mv88e6341_ops,
> +		.arr_ts_mode = offsetof(struct ptp_header, reserved2),
>  	},
>  
>  	[MV88E6350] = {
> @@ -6447,6 +6449,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
>  		.edsa_support = MV88E6XXX_EDSA_SUPPORTED,
>  		.ptp_support = true,
>  		.ops = &mv88e6352_ops,
> +		.arr_ts_mode = offsetof(struct ptp_header, reserved2),
>  	},
>  	[MV88E6361] = {
>  		.prod_num = MV88E6XXX_PORT_SWITCH_ID_PROD_6361,
> diff --git a/drivers/net/dsa/mv88e6xxx/hwtstamp.h b/drivers/net/dsa/mv88e6xxx/hwtstamp.h
> index c359821d5a6ea..c25f53923e768 100644
> --- a/drivers/net/dsa/mv88e6xxx/hwtstamp.h
> +++ b/drivers/net/dsa/mv88e6xxx/hwtstamp.h
> @@ -68,6 +68,20 @@
>  #define MV88E6XXX_PORT_PTP_CFG2_DEP_IRQ_EN		0x0002
>  #define MV88E6XXX_PORT_PTP_CFG2_ARR_IRQ_EN		0x0001
>  
> +/* Arrival Time Stamp Mode (ArrTSMode), CFG2 bits [15:8]: configures how the
> + * switch embeds the arrival time stamp (PTPArr0Time) into enabled PTP event
> + * frames.
> + *   0x00        frame modification disabled (time stamp read from registers)
> + *   0x01        append the 4-byte time stamp at the end of the frame,
> + *               growing the frame by four bytes
> + *   0x04..0xEF  overwrite the 4-byte time stamp in place, that many bytes past
> + *               the start of the PTP common header, without growing the frame
> + *               (offsetof(struct ptp_header, reserved2) targets the reserved
> + *               bytes of the header)
> + *   others      reserved
> + */
> +#define MV88E6XXX_PTP_ARR_TS_MODE_APPEND		0x01
> +
>  /* Offset 0x03: PTP LED Configuration */
>  #define MV88E6XXX_PORT_PTP_LED_CFG	0x03

We try to keep the data path protocol between the switch and the host
API compatible, and identifiable by /sys/class/net/<conduit>/dsa/tagging.
I would argue that the protocol where PTP timestamps are in registers,
vs where they are in PTP header reserved fields, vs where they are
appended as trailers, are 3 different protocols and should not be
presented as "edsa".

Two different switches both use the "edsa" protocol (say MV88E6390 and
MV88E6352), yet one expects timestamps in registers and the other in the
PTP header reserved fields. Strange.

In some instances, user space cares (though perhaps not imminently).
For example, libpcap/tcpdump might get confused by a non-zero arr_ts_mode.
Or an XDP/AF_XDP implementation of the edsa protocol might not understand
(because it has no access to this information) what arr_ts_mode the
underlying switch is configured for, and thus where to get timestamps from.