| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <Z_ZlDLzvu_Y2JWM8@shell.armlinux.org.uk> Date: Wed, 9 Apr 2025 13:16:12 +0100 From: "Russell King (Oracle)" <linux@...linux.org.uk> To: Kory Maincent <kory.maincent@...tlin.com> Cc: Simon Horman <horms@...nel.org>, Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Marek Behún <kabel@...nel.org>, Richard Cochran <richardcochran@...il.com>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>, Maxime Chevallier <maxime.chevallier@...tlin.com>, linux-kernel@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [PATCH net-next v2 2/2] net: phy: Add Marvell PHY PTP support 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@...linux.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@...linux.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!
Powered by blists - more mailing lists