Re: [PATCH net-next v2 2/2] net: phy: Add Marvell PHY PTP support
From: Russell King (Oracle)
Date: Wed Apr 09 2025 - 13:35:50 EST
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@xxxxxxxxxxxxxxx> 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!