Hi Vladimir,

ocelot_ptp_rx_timestamp() accesses MMIO-based registers, which can be
done atomically.
mv88e6xxx_ptp_clock_read() accesses MDIO bus registers, and the MDIO bus
is sleepable. Fundamental difference.

Your hardware only provides 32 bits of partial timestamp, so
mv88e6xxx_ptp_clock_read() will always be needed one way or another, to
recover the full 64 bits. Either through tstamp_{cc,tc} or through
direct calls.

This still happens from overflow_work().

quoted

Deferring to the worker can reorder frames such that PTP general
messages arrive before the timestamped event messages, which confuses
some other PTP implementations such as gptp2d [1].

True, this is a caveat, but event messages and general messages can
already take different network paths, especially with PTP over IP where
they go through different UDP ports (even if for gPTP that is not the case).
The PTP user space implementation needs to be prepared to handle this.

Good point. So perhaps processing the embedded timestamp inline doesn’t confer much benefit. ptp4l (which we use) handles out-of-order messages fine.

quoted

This optimisation of course only works for ArrTSMode because there is
no MDIO read required.

I don't understand this comment given the partial 32-bit timestamp
limitation.

Better phrased as no MDIO read to recover the arrival timestamp.

Luke