Re: [PATCH net-next v2 2/2] net: phy: Add Marvell PHY PTP support

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

On Wed, Apr 09, 2025 at 06:04:14PM +0200, Kory Maincent wrote:
> On Wed, 9 Apr 2025 14:35:17 +0100
> "Russell King (Oracle)" <linux@armlinux.org.uk> wrote:
> 
> > On Wed, Apr 09, 2025 at 02:38:20PM +0200, Kory Maincent wrote:
> > > Ok, thanks for the tests and these information.
> > > Did you run ptp4l with this patch applied and did you switch to Marvell PHY
> > > PTP source?  
> > 
> > This was using mvpp2, but I have my original patch as part of my kernel
> > rather than your patch.
> 
> So you are only testing the mvpp2 PTP. It seems there is something broken with
> it. I don't think it is related to my work.

Yes, and it has worked - but probably was never tested with PTPDv2 but
with linuxptp. As it was more than five years ago when I worked on this
stuff, I just can't remember the full details of the test setup I used.

I think the reason I gave up running PTP on my network is the problems
that having the NIC bound into a Linux bridge essentially means that
you can't participate in PTP on that machine. That basically means a
VM host machine using a bridge device for the guests can't use PTP
to time sync itself.

Well, it looks like the PHY based timestamping also isn't working -
ptp4l says its failing to timestamp transmitted packets, but having
added debug, the driver _is_ timestamping them, so the timestamps
are getting lost somewhere in the networking layer, or are too late
for ptp4l, which only waits 1ms, and the schedule_delayed_work(, 2) 
will be about 20ms at HZ=100. Increasing the wait in ptp4l to 100ms
still doesn't appear to get a timestamp. According to the timestamps
on the debug messages, it's only taking 10ms to return the timestamp.

So, at the moment, ptp looks entirely non-functional. Or the userspace
tools are broken.

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