On Tue, Nov 10, 2020 at 06:40:45PM +0200, Vladimir Oltean wrote: > I am fairly confident that this is how your hardware works, because > that's also how peer delay wants to be timestamped, it seems. So I was confident and also wrong, it appears. My KSZ9477 datasheet says: In the host-to-switch direction, the 4-byte timestamp field is always present when PTP is enabled, as shown in Figure 4-6. This is true for all packets sent by the host, including IBA packets. The host uses this field to insert the receive timestamp from PTP Pdelay_Req messages into the Pdelay_Resp messages. For all other traffic and PTP message types, the host should populate the timestamp field with zeros. Hm. Does that mean that the switch updates the originTimestamp field of the Sync frames by itself? Ok... Very interesting that they decided to introduce a field in the tail tag for a single type of PTP message. But something is still wrong if you need to special-case the negative correctionField, it looks like the arithmetic is not done on the correct number of bits, either by the driver or by the hardware. And zeroing out the correctionField of the Pdelay_Resp on transmission, to put that value into t_Tail_Tag? How can you squeeze a 48-bit value into a 32-bit value without truncation?
