Re: [RFC PATCH net-next 7/9] net: dsa: microchip: ksz9477: add hardware time stamping support

From: Christian Eggers
Date: Tue Nov 17 2020 - 06:28:48 EST


On Thursday, 12 November 2020, 16:28:44 CET, Christian Eggers wrote:
> Hi Vladimir,
>
> On Tuesday, 10 November 2020, 20:32:45 CET, Vladimir Oltean wrote:
> > 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.
>
> I got it!
I got it not!

While keeping the (negative) correction field works perfect when using
PTP over L2 (what I did the last weeks), this causes an unwanted side effect
when using UDP:

...
> User Datagram Protocol, Src Port: 319, Dst Port: 319
>
> Source Port: 319
> Destination Port: 319
> Length: 62
>
> Checksum: 0x2285 incorrect, should be 0x2286 (maybe caused by "UDP checksum offload"?)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> [Checksum Status: Bad]
> [Stream index: 0]
> [Timestamps]
>
> Precision Time Protocol (IEEE1588)
>
> 0000 .... = transportSpecific: 0x0
> .... 0011 = messageId: Peer_Delay_Resp Message (0x3)
> 0000 .... = Reserved: 0
> .... 0010 = versionPTP: 2
> messageLength: 54
> subdomainNumber: 0
> Reserved: 0
> flags: 0x0000
> correction: 5579788,000000 nanoseconds
> Reserved: 0
> ClockIdentity: 0x849000fffe0980f7
> SourcePortID: 1
> sequenceId: 785
> control: Other Message (5)
> logMessagePeriod: 127
> requestreceiptTimestamp (seconds): 0
> requestreceiptTimestamp (nanoseconds): 0
> requestingSourcePortIdentity: 0x849000fffe0980f6
> requestingSourcePortId: 2
While correction field is ok (residential delay ~5ms, using one printk...),
the UDP checksum is off by one in all PDelay_Resp messages.

The KSZ device offers on option to set the UDP checksum to zero, but this also
didn't help and additionally wouldn't work for IPv6.

It seems that I should return to "moving T2 from the correction field to the
tail tag" on tx.

regards
Christian