From: Vladimir Oltean <olte...@gmail.com>
Date: Sun, 29 Sep 2019 01:08:17 +0300

> Sometimes the PTP synchronization on the switch 'jumps':
 ...
> Background: the switch only offers partial RX timestamps (24 bits) and
> it is up to the driver to read the PTP clock to fill those timestamps up
> to 64 bits. But the PTP clock readout needs to happen quickly enough (in
> 0.135 seconds, in fact), otherwise the PTP clock will wrap around 24
> bits, condition which cannot be detected.
> 
> Looking at the 'max 134217731' value on output line 3, one can see that
> in hex it is 0x8000003. Because the PTP clock resolution is 8 ns,
> that means 0x1000000 in ticks, which is exactly 2^24. So indeed this is
> a PTP clock wraparound, but the reason might be surprising.
> 
> What is going on is that sja1105_tstamp_reconstruct(priv, now, ts)
> expects a "now" time that is later than the "ts" was snapshotted at.
> This, of course, is obvious: we read the PTP time _after_ the partial RX
> timestamp was received. However, the workqueue is processing frames from
> a skb queue and reuses the same PTP time, read once at the beginning.
> Normally the skb queue only contains one frame and all goes well. But
> when the skb queue contains two frames, the second frame that gets
> dequeued might have been partially timestamped by the RX MAC _after_ we
> had read our PTP time initially.
> 
> The code was originally like that due to concerns that SPI access for
> PTP time readout is a slow process, and we are time-constrained anyway
> (aka: premature optimization). But some timing analysis reveals that the
> time spent until the RX timestamp is completely reconstructed is 1 order
> of magnitude lower than the 0.135 s deadline even under worst-case
> conditions. So we can afford to read the PTP time for each frame in the
> RX timestamping queue, which of course ensures that the full PTP time is
> in the partial timestamp's future.
> 
> Fixes: f3097be21bf1 ("net: dsa: sja1105: Add a state machine for RX 
> timestamping")
> Signed-off-by: Vladimir Oltean <olte...@gmail.com>

Applied and queued up for -stable, thanks.

Reply via email to