All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Kory Maincent <kory.maincent@bootlin.com>,
	Marcin Wojtas <marcin.s.wojtas@gmail.com>,
	netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
	Richard Cochran <richardcochran@gmail.com>,
	Vladimir Oltean <olteanv@gmail.com>
Subject: Re: [PATCH RFC net-next 0/5] Marvell PTP support
Date: Fri, 11 Apr 2025 22:30:57 +0100	[thread overview]
Message-ID: <Z_mKEVwp1tXMsJdr@shell.armlinux.org.uk> (raw)
In-Reply-To: <Z_mI94gkKkBslWmv@shell.armlinux.org.uk>

On Fri, Apr 11, 2025 at 10:26:15PM +0100, Russell King (Oracle) wrote:
> Hi,
> 
> This series is a work in progress, and represents the current state of
> things, superseding Kory's patches which were based in a very old
> version of my patches - and my patches were subsequently refactored
> and further developed about five years ago. Due to them breaking
> mvpp2 if merged, there was no point in posting them until such time
> that the underlying issues with PTP were resolved - and they now have
> been.
> 
> Marvell re-uses their PTP IP in several of their products - PHYs,
> switches and even some ethernet MACs contain the same IP. It really
> doesn't make sense to duplicate the code in each of these use cases.
> 
> Therefore, this series introduces a Marvell PTP core that can be
> re-used - a TAI module, which handles the global parts of the PTP
> core, and the TS module, which handles the per-port timestamping.
> 
> I will note at this point that although the Armada 388 TRM states that
> NETA contains the same IP, attempts to access the registers returns
> zero, and it is not known if that is due to the board missing something
> or whether it isn't actually implemented. I do have some early work
> re-using this, but when I discovered that the TAI registers read as
> zero and wouldn't accept writes, I haven't progressed that.
> 
> Today, I have converted the mv88e6xxx DSA code to use the Marvell TAI
> module from patch 1, and for the sake of getting the code out there,

Correction: patch 2.

> I have included the "hacky" patches in this series - with the issues
> with DSA VLANs that I reported this evening and subsequently
> investigated, I've not had any spare time to properly prepare that
> part of this series. (Being usurped from phylink by stmmac - for which
> I have a big stack of patches that I can't get out because of being
> usurped, and then again by Marvell PTP, and then again by DSA VLAN
> stuff... yea, I'm feeling like I have zero time to do anything right
> now.) The mv88e6xxx DSA code still needs to be converted to use the
> Marvell TS part of patch 1, but I won't be able to test that after
> Sunday, and I'm certainly not working on this over this weekend.
> 
> Anyway, this is what it is - and this is likely the state of it for
> a while yet, because I won't be able to sensibly access the hardware
> for testing for an undefined period of time.
> 
> The PHY parts seem to work, although not 100% reliably, with the
> occasional overrun, particularly on the receive side. I'm not sure
> whether this is down to a hardware bug or not, or MDIO driver bug,
> because we certainly aren't missing timestamping a SKB. This has been
> tested at L2 and L4.
> 
> I'm not sure which packets we should be timestamping (remembering
> that this is global config across all ports.)
> https://chronos.uk/wordpress/wp-content/uploads/TechnicalBrief-IEEE1588v2PTP.pdf
> suggests Sync, Delay_req and Delay_resp need to be timestamped,
> possibly PDelay_req and PDelay_resp as well, but I haven't seen
> those produced by PTPDv2 nor ptp4l.
> 
> There's probably other stuff I should mention, but as I've been at
> this into the evening for almost every day this week, I'm mentally
> exhausted.
> 
> Sorry also if this isn't coherent.
> 
>  drivers/net/dsa/mv88e6xxx/Kconfig               |   1 +
>  drivers/net/dsa/mv88e6xxx/chip.h                |  26 +-
>  drivers/net/dsa/mv88e6xxx/hwtstamp.c            |  17 +-
>  drivers/net/dsa/mv88e6xxx/hwtstamp.h            |   1 +
>  drivers/net/dsa/mv88e6xxx/ptp.c                 | 519 ++++++++-------------
>  drivers/net/dsa/mv88e6xxx/ptp.h                 |   1 -
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c |   2 +
>  drivers/net/phy/Kconfig                         |  13 +
>  drivers/net/phy/Makefile                        |   1 +
>  drivers/net/phy/marvell.c                       |  21 +-
>  drivers/net/phy/marvell_ptp.c                   | 307 ++++++++++++
>  drivers/net/phy/marvell_ptp.h                   |  21 +
>  drivers/ptp/Kconfig                             |   4 +
>  drivers/ptp/Makefile                            |   2 +
>  drivers/ptp/ptp_marvell_tai.c                   | 449 ++++++++++++++++++
>  drivers/ptp/ptp_marvell_ts.c                    | 593 ++++++++++++++++++++++++
>  include/linux/marvell_ptp.h                     | 129 ++++++
>  17 files changed, 1764 insertions(+), 343 deletions(-)
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
> 

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

  parent reply	other threads:[~2025-04-11 21:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-11 21:26 [PATCH RFC net-next 0/5] Marvell PTP support Russell King (Oracle)
2025-04-11 21:26 ` [PATCH RFC net-next 1/5] net: mvpp2: add support for hardware timestamps Russell King
2025-04-11 21:29   ` Russell King (Oracle)
2025-04-14 12:51   ` Kory Maincent
2025-04-14 14:43     ` Russell King (Oracle)
2025-04-14 15:02       ` Kory Maincent
2025-04-11 21:26 ` [PATCH RFC net-next 2/5] ptp: marvell: add core support for Marvell PTP v2.1 Russell King
2025-04-11 21:30   ` Russell King (Oracle)
2025-04-16  8:48   ` Kory Maincent
2025-04-16  9:22     ` Russell King (Oracle)
2025-04-16 13:14       ` Kory Maincent
2025-06-13 15:19       ` Kory Maincent
2025-10-03 13:09         ` Casper Andersson
2025-04-11 21:26 ` [PATCH RFC net-next 3/5] net: phy: add Marvell PHY PTP support Russell King
2025-04-14 12:33   ` Kory Maincent
2025-04-14 12:37     ` Russell King (Oracle)
2025-04-14 13:57     ` Russell King (Oracle)
2025-04-14 14:43   ` Kory Maincent
2025-04-14 14:55     ` Russell King (Oracle)
2025-04-14 15:21       ` Kory Maincent
2025-04-14 16:16         ` Kory Maincent
2025-04-14 16:35           ` Russell King (Oracle)
2025-04-11 21:26 ` [PATCH RFC net-next 4/5] mv88e6xxx: convert to marvell TAI Russell King (Oracle)
2025-04-11 21:26 ` [PATCH RFC net-next 5/5] mv88e6xxx: cleanup ptp tai Russell King (Oracle)
2025-04-11 21:30 ` Russell King (Oracle) [this message]
2025-04-16 10:51 ` [PATCH RFC net-next 0/5] Marvell PTP support Russell King (Oracle)
2025-04-16 13:19   ` Kory Maincent
2025-04-16 14:13     ` Russell King (Oracle)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z_mKEVwp1tXMsJdr@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kory.maincent@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=marcin.s.wojtas@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.