From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E3227FD4F08 for ; Tue, 10 Mar 2026 17:19:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NMdjOrVXXHLK8N0yejqmWl7GRk54LT5Y+qMFtI5pbCY=; b=FW8H+ZZ0acsYuB frf0PggqnFm9Zu03uCrLBxCbXRWb2CHoGWyj0CkFC8lELLaSGSyAyktQwJhDCxJt5So+eqJyy+C6w GrowArSPEKbVgHMkbZR5h7NffY1MFpGwwoNDPHv3nwbaIaMdnp1owoBZennLDLUNyNxwSHMajLOE/ hvFqcy0gfTUkU+Hot9WsiUp+sGXKOUjWCcAthzFZI8h1zP+gDsrDM5O1uJ65laQv3n9AuzZLVGG3c T9JYhWmuphUwH+p42BK+yqjUHg2m3b2aebHsbdMZ7LFKMICMKGF+FG5IQ4pqF6o2YQdhYW7QP8hTt PaRXZXTqI2wLxd5QzGQg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w00jv-00000009xzc-3pLs; Tue, 10 Mar 2026 17:19:27 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w00jt-00000009xxO-23FY for linux-riscv@lists.infradead.org; Tue, 10 Mar 2026 17:19:26 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 1E391408FE; Tue, 10 Mar 2026 17:19:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ACBCAC19425; Tue, 10 Mar 2026 17:19:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773163165; bh=XKo6oEcfxrAO5a6uL1jOlJ673A3wAiggYrYhD1OOv/s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sNQGP8awIFmI2BSob6KCi/mtqeHWypqZQig0okBXP8w8ZiDMRwXbUXpJXJpYRh/+5 NMhyb4ut+zCHRctYZMaZqnmwsTFJjSSh6VX0Z9JLnXf9ZFJF9Jit7W89qmyBCy6h2F OlT0BcBKhQZnCAlYTHkzW+iLoMGy/EaRZBy+krRUCxSkC6539O1//86z8DX1BC4kSx QNpa6vkoK3XlY5fCiiCGZ4ClUl15Y94LYMExbZIVNoYMcr6IJFSvXaYlXDqKfFTx47 Zvq871TL0AxKknXARgdeQAuy1/BnZQoMOpE1V7IAblLB7DV2KIbk7HJ5MC/vi5VOzj OM/fo7QTgYMKw== From: Conor Dooley To: netdev@vger.kernel.org Cc: conor@kernel.org, Conor Dooley , Valentina.FernandezAlanis@microchip.com, Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Daire McNamara , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Nicolas Ferre , Claudiu Beznea , Richard Cochran , Samuel Holland , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Dave Stevenson , Sean Anderson , Vineeth Karumanchi , Abin Joseph , =?UTF-8?q?Th=C3=A9o=20Lebrun?= , Ryan.Wanner@microchip.com Subject: [PATCH net-next v3 07/10] net: macb: warn on pclk use as a tsu_clk fallback Date: Tue, 10 Mar 2026 17:17:14 +0000 Message-ID: <20260310-unsubtle-velvet-4bb458cc06ba@spud> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260310-moneyless-dispense-7bce14b16388@spud> References: <20260310-moneyless-dispense-7bce14b16388@spud> MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3276; i=conor.dooley@microchip.com; h=from:subject:message-id; bh=NwKelKp1tigxckCA+KrqnMxOmrCbE/r2GTIcp/cWLQA=; b=owGbwMvMwCVWscWwfUFT0iXG02pJDJkbgvS2BG/8Wp10pvJn4NknK19+fvX1b+aea4FLi7305 qx3WK34vKOUhUGMi0FWTJEl8XZfi9T6Py47nHvewsxhZQIZwsDFKQATebCNkWH3niuXnzXe67Q3 e1adLzT7lGTwHamyCV8LH8zYNIGRVaiE4X+sy+zda+L7unUWqK+KrZeW3WFg6CbPLPGq5dfhv1I 7PdgA X-Developer-Key: i=conor.dooley@microchip.com; a=openpgp; fpr=F9ECA03CF54F12CD01F1655722E2C55B37CF380C X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260310_101925_574747_A6AB2E56 X-CRM114-Status: GOOD ( 21.93 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org From: Conor Dooley The Candence GEM IP has a configuration parameter which determines the source of the clock used for the timestamp unit (if it is enabled), switching it between using the pclk and a dedicated input. When ptp support was added to the macb driver, a new tsu_clk was added to represent the dedicated input. While this is understandable, I think it is bug prone and that the tsu_clk should represent whatever clock is used for the timestamper and not just that specific input. >>From a driver point of view, the benefit of taking the conceptual approach is avoiding misconfiguring the driver when the hardware supports ptp (and it is set as a capability in the relevant per-device structure) but no tsu_clk is provided in devicetree. At the moment, the timestamper will be registered and programmed with an increment that reflects the pclk in these cases, but will malfunction if the pclk and tsu_clk frequencies do not match. Obviously, this means the devicetree incorrectly represents the hardware, but this change in approach would make the driver more resilient without meaningfully impacting correctly described users. Out of the devices that claim MACB_CAPS_GEM_HAS_PTP the fu540, mpfs, sama5d2 and sama7g5-emac (but not sama7g5-gem) are at risk of having this problem with the in-kernel devicetrees. mpfs and sama7g5-emac have been confirmed to be incorrect, and sama5d2 is correct. It may be that the other platforms actually do use the pclk for the timestamper (either by supplying pclk to the tsu_clk input of the IP, or by having the IP block configured to use pclk instead of the tsu_clk input), but at least two are wrong, as they do not use pclk for the tsu_clk, so the driver is registering the ptp clock incorrectly. Add a warning if no tsu_clk is provided on a platform that uses the timerstamper, to encourage people to specifically provide a tsu_clk and avoid silently registering the timerstamper with the wrong clock. If the pclk is actually used, it can be provided as a tsu_clk for improved clarity in devicetrees. While this changes the meaning of the devicetree property, it is backwards compatible as there's no functional change for platforms that didn't provide a tsu_clk and the changed meaning of providing a tsu_clk in the devicetree does not impact platforms that already provided one as the decision about the tsu clock source is at IP instantiation time rather than at runtime, so there's no driver behaviour that needs to change based on the input to the IP used for the timestamping unit. Signed-off-by: Conor Dooley --- drivers/net/ethernet/cadence/macb_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c index b476bc9663ecd..6b37598ac57cd 100644 --- a/drivers/net/ethernet/cadence/macb_main.c +++ b/drivers/net/ethernet/cadence/macb_main.c @@ -3534,6 +3534,7 @@ static unsigned int gem_get_tsu_rate(struct macb *bp) else if (!IS_ERR(bp->pclk)) { tsu_clk = bp->pclk; tsu_rate = clk_get_rate(tsu_clk); + dev_warn(&bp->pdev->dev, "devicetree missing tsu_clk, using pclk as fallback\n"); } else return -ENOTSUPP; return tsu_rate; -- 2.51.0 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv