Re: [PATCH net-next v2 2/2] net: dsa: mv88e6xxx: embedded PTP timestamp support
From: Vladimir Oltean <olteanv@gmail.com>
Date: 2026-07-19 10:12:46
Also in:
lkml
On Fri, Jul 10, 2026 at 04:43:42PM +1000, Luke Howard wrote:
quoted hunk ↗ jump to hunk
@@ -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.