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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z_gLD8XFlyG32D6L@shell.armlinux.org.uk>
Date: Thu, 10 Apr 2025 19:16:47 +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 Thu, Apr 10, 2025 at 06:02:05PM +0200, Kory Maincent wrote:
> On Thu, 10 Apr 2025 16:41:06 +0100
> "Russell King (Oracle)" <linux@...linux.org.uk> wrote:
> 
> > On Thu, Apr 10, 2025 at 11:17:54AM +0200, Kory Maincent wrote:
> > > On Wed, 9 Apr 2025 23:38:00 +0100
> > > "Russell King (Oracle)" <linux@...linux.org.uk> wrote:  
> > > > On Wed, Apr 09, 2025 at 06:34:35PM +0100, Russell King (Oracle) wrote:  
> 
> > > > 
> > > > With that fixed, ptp4l's output looks very similar to that with mvpp2 -
> > > > which doesn't inspire much confidence that the ptp stack is operating
> > > > properly with the offset and frequency varying all over the place, and
> > > > the "delay timeout" messages spamming frequently. I'm also getting
> > > > ptp4l going into fault mode - so PHY PTP is proving to be way more
> > > > unreliable than mvpp2 PTP. :(  
> > > 
> > > That's really weird. On my board the Marvell PHY PTP is more reliable than
> > > MACB. Even by disabling the interrupt.
> > > What is the state of the driver you are using?   
> > 
> > Right, it seems that some of the problems were using linuxptp v3.0
> > rather than v4.4, which seems to work better (in that it doesn't
> > seem to time out and drop into fault mode.)
> > 
> > With v4.4, if I try:
> > 
> > # ./ptp4l -i eth2 -m -s -2
> > ptp4l[322.396]: selected /dev/ptp0 as PTP clock
> > ptp4l[322.453]: port 1 (eth2): INITIALIZING to LISTENING on INIT_COMPLETE
> > ptp4l[322.454]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on
> > INIT_COMPLETE ptp4l[322.455]: port 0 (/var/run/ptp4lro): INITIALIZING to
> > LISTENING on INIT_COMPLETE ptp4l[328.797]: selected local clock
> > 005182.fffe.113302 as best master
> > 
> > that's all I see. If I drop the -2, then:
> 
> It seems you are still using your Marvell PHY drivers without my change.
> PTP L2 was broken on your first patch and I fixed it.
> I have the same result without the -2 which mean ptp4l uses UDP IPV4.

I'm not sure what you're referring to.

There isn't any change for the packet offsets in your patch in
https://termbin.com/gzei

You added configuration of the PTP global config 1 register, which
is already in my patches - I was writing ~0 to that, you were writing
3. This only changes which PTP MSGID values get timestamped. I've been
trying your value of 3 here just in case it was significant.

You changed to use ptp_parse_header() (which didn't exist at the time
you took my patch) and I had already updated my patches to use when
this new helper was introduced.

The overflow_ns change you made in https://termbin.com/6a18 doesn't
apply to my code, because my code became:

        overflow_ns = BIT_ULL(32) * param->cc_mult;
        overflow_ns >>= param->cc_shift;
        tai->half_overflow_period = nsecs_to_jiffies64(overflow_ns / 2);

with overflow_ns being a u64.

I think that covers everything that has a functional change in terms
of packet parsing either by the driver or by the hardware, so I'm not
sure what problem you are referring to, or what your fix for it is -
maybe it's not in either of these two patches?

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