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 10:48:58AM +0200, Kory Maincent wrote:
> On Wed, 9 Apr 2025 09:33:09 +0100
> "Russell King (Oracle)" <linux@armlinux.org.uk> wrote:
> 
> > On Wed, Apr 09, 2025 at 10:18:08AM +0200, Kory Maincent wrote:
> > > On Tue, 8 Apr 2025 18:32:04 +0100
> > > "Russell King (Oracle)" <linux@armlinux.org.uk> wrote:
> > >   
> > > > On Tue, Apr 08, 2025 at 04:49:34PM +0100, Simon Horman wrote:  
> >  [...]  
> >  [...]  
> >  [...]  
> >  [...]  
> >  [...]  
> > > > 
> > > > ... and anyway, I haven't dropped my patches, I'm waiting for the
> > > > fundamental issue with merging Marvell PHY PTP support destroying the
> > > > ability to use MVPP2 PTP support to be solved, and then I will post
> > > > my patches.
> > > > 
> > > > They aren't dead, I'm just waiting for the issues I reported years ago
> > > > with the PTP infrastructure to be resolved - and to be tested as
> > > > resolved.
> > > > 
> > > > I'm still not convinced that they have been given Kory's responses to
> > > > me (some of which I honestly don't understand), but I will get around
> > > > to doing further testing to see whether enabling Marvell PHY PTP
> > > > support results in MVPP2 support becoming unusable.
> > > > 
> > > > Kory's lack of communication with me has been rather frustrating.  
> > > 
> > > You were in CC in all the series I sent and there was not a lot of review
> > > and testing on your side. I know you seemed a lot busy at that time but I
> > > don't understand what communication is missing here?   
> > 
> > I don't spend much time at the physical location where the hardware that
> > I need to test your long awaited code is anymore. That means the
> > opportunities to test it are *rare*.
> > 
> > So far, each time I've tested your code, it's been broken. This really
> > doesn't help.
> > 
> > If you want me to do anything more in a timely manner, like test fixes,
> > you need to get them to me by the end of this week, otherwise I won't
> > again be able to test them for a while.
> 
> You could try again with Vlad patch adding support to ndo_hwtstamp_get/set to
> the mvpp2 drivers.
> https://github.com/vladimiroltean/linux/commit/5bde95816f19cf2872367ecdbef1efe476e4f833

Well, I'm not sure PTP is working correctly.

On one machine (SolidRun Hummingboard 2), I'm running ptpd v2:

2025-04-09 11:34:19.590032 ptpd2[7284].startup (info)      (___) Configuration OK
2025-04-09 11:34:19.594624 ptpd2[7284].startup (info)      (___) Successfully acquired lock on /var/run/ptpd2.lock
2025-04-09 11:34:19.596099 ptpd2[7284].startup (notice)    (___) PTPDv2 started successfully on end0 using "masteronly" preset (PID 7284)
2025-04-09 11:34:19.596347 ptpd2[7284].startup (info)      (___) TimingService.PTP0: PTP service init
# Timestamp, State, Clock ID, One Way Delay, Offset From Master, Slave to Master, Master to Slave, Observed Drift, Last packet Received, One Way Delay Mean, One Way Delay Std Dev, Offset From Master Mean, Offset From Master Std Dev, Observed Drift Mean, Observed Drift Std Dev, raw delayMS, raw delaySM
2025-04-09 11:34:19.596685, init,
2025-04-09 11:34:19.699787 ptpd2[7284].end0 (notice)    (lstn_init) Now in state: PTP_LISTENING
2025-04-09 11:34:19.699915, lstn_init,  1
2025-04-09 11:34:29.596621 ptpd2[7284].end0 (notice)    (lstn_init) TimingService.PTP0: elected best TimingService
2025-04-09 11:34:29.596758 ptpd2[7284].end0 (info)      (lstn_init) TimingService.PTP0: acquired clock control
2025-04-09 11:34:31.701104 ptpd2[7284].end0 (notice)    (mst) Now in state: PTP_MASTER, Best master: d063b4fffe0243c3(unknown)/1 (self)
2025-04-09 11:34:31.701369, mst, d063b4fffe0243c3(unknown)/1

with this configuration:

ptpengine:interface=end0
ptpengine:preset=masteronly
ptpengine:multicast_ttl=1
clock:no_adjust=y
clock:no_reset=y

On the test machine (Macchiatobin), I'm running linuxptp ptp4l:

# ./ptp4l -i eth2 -m -s -l 7
...
ptp4l[2701.638]: master offset     -30111 s2 freq  -91915 path delay     63039
ptp4l[2701.725]: port 1: delay timeout
ptp4l[2701.726]: delay   filtered      63039   raw      40846
ptp4l[2702.253]: port 1: delay timeout
ptp4l[2702.254]: delay   filtered      63039   raw      43806
ptp4l[2702.638]: master offset      29689 s2 freq  -41148 path delay     63039
ptp4l[2703.638]: master offset     -14050 s2 freq  -75981 path delay     63039
ptp4l[2703.993]: port 1: delay timeout
ptp4l[2703.993]: delay   filtered      62371   raw      48094
ptp4l[2704.255]: port 1: delay timeout
ptp4l[2704.255]: delay   filtered      61726   raw      49767
ptp4l[2704.638]: master offset      16434 s2 freq  -49712 path delay     61726
ptp4l[2705.570]: port 1: delay timeout
ptp4l[2705.571]: delay   filtered      61726   raw      68302
ptp4l[2705.638]: master offset     -33159 s2 freq  -94374 path delay     61726
ptp4l[2706.638]: master offset      28762 s2 freq  -42401 path delay     61726
ptp4l[2707.254]: port 1: delay timeout

The "delay timeout" and random master offsets doesn't look like PTP is
working correctly.

tcpdump on the Macchiatobin shows:

13:08:34.701122 d0:63:b4:02:43:c3 > 01:00:5e:00:01:81, ethertype IPv4 (0x0800), length 86: 192.168.0.240.319 > 224.0.1.129.319: PTPv2, v1 compat : no, msg type : sync msg, length : 44, domain : 0, reserved1 : 0, Flags [two step], NS correction : 0, sub NS correction : 0, reserved2 : 0, clock identity : 0xd063b4fffe0243c3, port id : 1, seq id : 5642, control : 0 (Sync), log message interval : 0, originTimeStamp : 1744200514 seconds, 700022395 nanoseconds
13:08:34.701123 d0:63:b4:02:43:c3 > 01:00:5e:00:01:81, ethertype IPv4 (0x0800), length 86: 192.168.0.240.320 > 224.0.1.129.320: PTPv2, v1 compat : no, msg type : follow up msg, length : 44, domain : 0, reserved1 : 0, Flags [none], NS correction : 0, sub NS correction : 0, reserved2 : 0, clock identity : 0xd063b4fffe0243c3, port id : 1, seq id : 5642, control : 2 (Follow_Up), log message interval : 0, preciseOriginTimeStamp : 1744200514 seconds, 700078731 nanoseconds
13:08:35.146133 00:51:82:11:33:02 > 01:00:5e:00:01:81, ethertype IPv4 (0x0800), length 86: 192.168.1.96.319 > 224.0.1.129.319: PTPv2, v1 compat : no, msg type : delay req msg, length : 44, domain : 0, reserved1 : 0, Flags [none], NS correction : 0, sub NS correction : 0, reserved2 : 0, clock identity : 0x5182fffe113302, port id : 1, seq id : 13, control : 1 (Delay_Req), log message interval : 127, originTimeStamp : 0 seconds, 0 nanoseconds
13:08:35.146529 d0:63:b4:02:43:c3 > 01:00:5e:00:01:81, ethertype IPv4 (0x0800), length 96: 192.168.0.240.320 > 224.0.1.129.320: PTPv2, v1 compat : no, msg type : delay resp msg, length : 54, domain : 0, reserved1 : 0, Flags [none], NS correction : 0, sub NS correction : 0, reserved2 : 0, clock identity : 0xd063b4fffe0243c3, port id : 1, seq id : 13, control : 3 (Delay_Resp), log message interval : 0, receiveTimeStamp : 1744200515 seconds, 145324449 nanoseconds, port identity : 0x5182fffe113302, port id : 1
13:08:35.701268 d0:63:b4:02:43:c3 > 01:00:5e:00:01:81, ethertype IPv4 (0x0800), length 106: 192.168.0.240.320 > 224.0.1.129.320: PTPv2, v1 compat : no, msg type : announce msg, length : 64, domain : 0, reserved1 : 0, Flags [none], NS correction : 0, sub NS correction : 0, reserved2 : 0, clock identity : 0xd063b4fffe0243c3, port id : 1, seq id : 2821, control : 5 (Other), log message interval : 1, originTimeStamp : 0 seconds 0 nanoseconds, origin cur utc :0, rsvd : 130, gm priority_1 : 128, gm clock class : 13, gm clock accuracy : 254, gm clock variance : 65535, gm priority_2 : 128, gm clock id : 0xd063b4fffe0243c3, steps removed : 0, time source : 0xa0
13:08:35.701268 d0:63:b4:02:43:c3 > 01:00:5e:00:01:81, ethertype IPv4 (0x0800), length 86: 192.168.0.240.319 > 224.0.1.129.319: PTPv2, v1 compat : no, msg type : sync msg, length : 44, domain : 0, reserved1 : 0, Flags [two step], NS correction : 0, sub NS correction : 0, reserved2 : 0, clock identity : 0xd063b4fffe0243c3, port id : 1, seq id : 5643, control : 0 (Sync), log message interval : 0, originTimeStamp : 1744200515 seconds, 700230163 nanoseconds

So we can see that ptpdv2 is responding to the delay requests, but it
seems that ptp4l doesn't see them, but it is seeing the other messages
from the HB2 running in master mode. I don't have time to investigate
any further until later today, and then again not until tomorrow
evening.

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