Re: [PATCH net-next v2 0/2] net: dsa: mv88e6xxx: various hwstamp fixes

[Vladimir Oltean <olteanv@gmail.com>]

On Fri, Jul 17, 2026 at 05:47:49PM +1000, Luke Howard wrote:
> 
> > ---
> > Luke Howard (2):
> >    net: dsa: mv88e6xxx: embedded PTP timestamp support
> 
> This can be improved: there is no need to extract the embedded
> timestamp in the PTP worker as it can be done directly in
> mv88e6xxx_port_rxtstamp() (provided tstamp_{cc,tc} are protected by a
> spinlock). DSA can deliver the frame normally, similar to
> ocelot_ptp_rx_timestamp().

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.

> 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.

> 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.

> Luke
> 
> [1] https://github.com/xl4-shiro/excelfore-gptp