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

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

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@armlinux.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@armlinux.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!