From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 41C26606A31C for ; Fri, 13 Nov 2026 09:06:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=qfFrAcZG; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=dkim header.b=f0vffpVZ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Unsubscribe-Post: List-Owner; bh=m9B2HLqDdiE/y5FWXTFo38VfZGVo4F39dSrwK05GBbY=; b=qfFrAcZGuQl9ku 0yBX9lgUOIh1/fomttj5spHAAFtXZwZ/I9LHB6YGQE9ohYWv3qu+fa/n4Ek7uMoxQsDpIKhamPwgj lFewd3XgdgI7XAPnaZMpGiVY9AQS8/KFiKFH05jFK0zKIk4W+t8JAkU1ojTHnhj6v5S62z2DndwaV 7/TmBjcOThRZHLkBTtsrXP1zjXSyAd5uvE+MaDisK9U7h8uT3TPIKald/X8XazXE0Z0C52mPaxQoW OMuZJbAS9ZZHYfMP9+2gbVfMf7W9qtVOpA2BeigR//KZCeW7fyd4wATcCU0TDo5UOTc0r+nhx8HcZ WfGmifLQ2DW84bZnBvBw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xRnEh-0000000CBO1-2rmr; Fri, 13 Nov 2026 09:06:19 +0000 Received: from smtpout-02.galae.net ([185.246.84.56]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xRnEK-0000000CBKn-12Rn for linux-arm-kernel@lists.infradead.org; Fri, 13 Nov 2026 09:06:17 +0000 Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id 14E5E1A164C; Fri, 13 Nov 2026 09:05:53 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id D57B7601D5; Fri, 13 Nov 2026 09:05:52 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 1469611BC04C2; Fri, 13 Nov 2026 10:05:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1794560752; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=m9B2HLqDdiE/y5FWXTFo38VfZGVo4F39dSrwK05GBbY=; b=f0vffpVZZrslinjhbIpY9qf8M3/CTvC1z9yRuJJogyIu+IMIeQXQfStNZCfvTBfaholj0T XaUi5RncKXMF7GgfOhQVDBRYLBVRFb5xKn4JFbmA7GBQjCWX675/Mp4q0uAlmhPbkYexMp 9BVS2T1GmGDfln9dDKXTOClFTBVMsv+n0CadBkAkLrnTz494mmEpVvD8eiqM0gdGSByExO bEJoOGwXZBlIhKafG9ATQYOfWbZvmV28m3FFXd0ZU1yGK8PgofIRLbNVkIbZrZwQAxmfD6 4SgqesLYSHv0C1TIzkodXek6GjHCpZ0gw2QZYIxh9kwnrThjZzgVWgWre5XuhQ== Message-ID: <03612a8a-0899-47e9-b992-d166bc7fd63a@bootlin.com> Date: Fri, 13 Nov 2026 10:05:43 +0100 X-Archived-By: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net] net: stmmac: re-base EST after PTP settime64 To: Lorenzo Bianconi Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Alexandre Torgue , Richard Cochran , Jose Abreu , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20261111-stmmac_set_time-est_lock-v1-1-da1554f233e6@oss.qualcomm.com> From: Maxime Chevallier Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20261113_010556_477072_C252A9B7 X-CRM114-Status: GOOD ( 13.56 ) X-Spam-Score: -2.1 (--) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" X-Spam-Status: No, score=-17.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 Hi, On 11/13/26 09:48, Lorenzo Bianconi wrote: > On Nov 12, Maxime Chevallier wrote: >> Hi Lorenzo, >> >> On 11/11/26 10:54, Lorenzo Bianconi wrote: >>> stmmac_set_time() initializes the PTP clock through >>> stmmac_init_systime() (TSINIT) while holding only ptp_lock. It neither >>> takes est_lock nor disables and re-bases EST around the step, unlike >>> stmmac_adjust_time(), which performs TSUPDT through >>> stmmac_adjust_systime() under est_lock. >>> >>> Both operations change the PHC system time, so both invalidate the >>> absolute EST base time. With settime64, a concurrent >>> tc_taprio_configure() can read the pre-step clock through gettimex64() >>> and program EST with a base time that is already stale once TSINIT >>> lands. Separately, a taprio offload installed before the clock_settime() >>> is never re-based and keeps running with its old base time until taprio >>> is reconfigured. >>> >>> Take est_lock for the whole disable/step/reprogram sequence, as >>> stmmac_adjust_time() does: disable EST before initializing the clock and >>> call __stmmac_setup_est() afterwards so the base time is recomputed from >>> the reserved taprio base time and the new clock. >>> >>> This keeps the established est_lock -> ptp_lock ordering: >>> stmmac_init_systime() only uses readl_poll_timeout_atomic() under >>> ptp_lock, and __stmmac_setup_est() takes ptp_lock through gettimex64(). >>> >>> Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API") >>> Signed-off-by: Lorenzo Bianconi >> >> This LGTM, the return values from stmmac_est_configure/__stmmac_setup_est are >> ignored though, the [cl|s]ashiko gang may not like that. >> >> Besides one of the EST commands timing out, it seems unlikely though. > > I used the same approach used in stmmac_adjust_time(). I guess we can update > both of them if required. Bah, I'm OK doing that as a followup then, Reviewed-by: Maxime Chevallier Maxime > > Regards, > Lorenzo > >> >> Maxime >> >>> --- >>> drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c | 9 +++++++++ >>> 1 file changed, 9 insertions(+) >>> >>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c >>> index 31a66e855d6b..6370bdc6c58b 100644 >>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c >>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c >>> @@ -129,10 +129,19 @@ static int stmmac_set_time(struct ptp_clock_info *ptp, >>> container_of(ptp, struct stmmac_priv, ptp_clock_ops); >>> unsigned long flags; >>> >>> + mutex_lock(&priv->est_lock); >>> + if (priv->est && priv->est->enable) >>> + stmmac_est_configure(priv, priv, priv->est, >>> + priv->plat->clk_ptp_rate, false); >>> + >>> write_lock_irqsave(&priv->ptp_lock, flags); >>> stmmac_init_systime(priv, priv->ptpaddr, ts->tv_sec, ts->tv_nsec); >>> write_unlock_irqrestore(&priv->ptp_lock, flags); >>> >>> + if (priv->est && priv->est->enable) >>> + __stmmac_setup_est(priv); >>> + mutex_unlock(&priv->est_lock); >>> + >>> return 0; >>> } >>> >>> >>> --- >>> base-commit: 22b7cb932c6a0f7566d41072be6956cb6c8af4e1 >>> change-id: 20261111-stmmac_set_time-est_lock-f74f4ce678b7 >>> >>> Best regards, >>