Re: [PATCH RFC net-next] net: phy: add Marvell PHY PTP support [multicast/DSA issues]

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Tue, Feb 28, 2023 at 05:44:35PM +0100, Michael Walle wrote:
> >> 4. Letting drivers override PHY at run time.
> >
> > I think this is the only sensible solution - we know for example that
> > mvpp2 will prefer its PTP implementation as it is (a) higher resolution
> > and (b) has more flexibility than what can be provided by the Marvell
> > PHYs that it is often used with.
> 
> Please also consider that there might be one switch with a shared
> PHC and multiple PHYs, each with its own PHC.

Doesn't the PTP API already allow that? The PHC is a separate API from
the network hardware timestamping - and the netdev/PHY is required
to implement the ethtool get_ts_info API that provides userspace with
the index to the PHC associated with the interface.

> In this case, it is a
> property of the board wether PHY timestamping actually works, because
> it will need some kind of synchronization between all the PHYs.

How is this any different from e.g. a platform where there are
multiple network interfaces each with their own independent PHC
such as Macchiatobin, where there are two CP110 dies, each with
their own group of three ethernet adapters, and each die has its
own PHC shared between the three ethernet adapters?

Hardware synchronisation between the two PHCs isn't possible, but
they might tick at the same rate (it's something that hasn't been
checked.) However, the hardware signals aren't that helpful because
there's no way to make e.g. the rising edge always be at the start
of a second. So the synchronisation has to be done in software.

I don't think PHCs need to be synchronised in hardware to "actually
work". Take an example of a PC with two network cards, both having
their own independent PHC.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!