From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D3C528CF60 for ; Fri, 11 Apr 2025 21:31:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744407065; cv=none; b=RmyL8cWVgScYx1ls/QbS1fXirVRzhtYDEySt4C2Bd/DAiDo6Cgj7dFHZb2QcR2qC5SkcPpR8CP8XuWG7o9GplEY5gFNbWZ47osLt8gMXhrWmth1gBQsSuVfOEbGMdNRmDveTBur+IZYsMk2fWX+lBJy3WSbUCNjSIF0Xhp9k7hc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744407065; c=relaxed/simple; bh=q4Mx8C0N4oxivl40Jwc5N2ASBlhM17dqchZeV3gA2ng=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IxSqTIV1z7cYGfnxYzgSik7+wTt9YYelr9w66qldw313e+1yjoh3Xn1AYM+WcItkwkLpsCG+XiLqFGmK5hSGYifuORpNncFPgIC2F5QH1RIYStQh7rSEhX6ZRaXGEFoztMbcxw8Z3xElTQUpIYIQC8SqeMNDRxdPdy02IBezMps= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=rOlpn+SF; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="rOlpn+SF" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zOebsP5Wd+9+esFUfRPcHA4C39JkYxV8/m9rWyUv9u4=; b=rOlpn+SF1rNu0Hsq/7B5pIolU5 i55U0QEAJ7/xAk7GS0ImfjOQQHsMuUZzdrv7oyx2dupZZIFgl8S5Sc77pkYhoeIss5VJxI8b8Su2B O4dcRWdbyJhqR056X/Vp2ar5TaghU7YypRkiWf739alLwjgKPIa0zrAXMmqYkfbuUd7P3/7qhQ8ZK wv4EtWFf3nb1k4Qy6pZKIEm4bnKUHchhFQqLZRn5V5ojEA2YLex1yxLSr7WGltbIjMhyLPyDXkEQK 0p4DqyR5dgfKaW9R8RU1cPTk7xh5w+aif6AnldXmHdtloJ7fZf5wpzJNp02hKcnvCTE7Z0iUag+9V YRSSuUJA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:45166) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u3Lxi-0003tD-2C; Fri, 11 Apr 2025 22:30:58 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.96) (envelope-from ) id 1u3Lxh-0004xN-15; Fri, 11 Apr 2025 22:30:57 +0100 Date: Fri, 11 Apr 2025 22:30:57 +0100 From: "Russell King (Oracle)" To: Andrew Lunn , Heiner Kallweit Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Kory Maincent , Marcin Wojtas , netdev@vger.kernel.org, Paolo Abeni , Richard Cochran , Vladimir Oltean Subject: Re: [PATCH RFC net-next 0/5] Marvell PTP support Message-ID: References: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Russell King (Oracle) 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!