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: [PATCH RFC net-next 0/5] Marvell PTP support
Date: Fri, 11 Apr 2025 22:26:15 +0100 [thread overview]
Message-ID: <Z_mI94gkKkBslWmv@shell.armlinux.org.uk> (raw)
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,
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!
next reply other threads:[~2025-04-11 21:26 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-11 21:26 Russell King (Oracle) [this message]
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 ` [PATCH RFC net-next 0/5] Marvell PTP support Russell King (Oracle)
2025-04-16 10:51 ` 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_mI94gkKkBslWmv@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).