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 F0EA735CB88 for ; Mon, 23 Feb 2026 12:19:14 +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=1771849156; cv=none; b=TxIwXFqoUFfn/C0GHbcswuXkkD2z0XOBX90SZUtgpRLRtYbhkPJ2D9s0u46yPQE1fdnH9odA6MOD9Uo3A7sf1ucgop0iqMbSy0UyrZ3gQzz4w+0836TMBCyTl3ZqdA/Nfmx5CNw/fnzwN2r+9nmqZ2iWcusIzhdfdw7G+dgtTrc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771849156; c=relaxed/simple; bh=nJglFK05RLXV/jod4Jm6pswEmNetB55TExNSkpySwg4=; h=From:To:Cc:Subject:MIME-Version:Content-Disposition:Content-Type: Message-Id:Date; b=AL3xbWX/EGq73QkI7Q1wIcwytJNl0vA2BBebacJwi2H2WuqOsyP+hSBmrOsW7A/rTv/1OBAsTftH5FUfJqxN9+7zP045ez/BAhVrMaCaVGHVAu3C1LzaURqcS675q5/ZmEJGNnJU2D2BrnbEsCVnlAHoPpIAsWD12x4X+q0ZQNc= 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=WrtQiZJN; 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="WrtQiZJN" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Date:Sender:Message-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:Subject:Cc:To:From:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Jo6I6WwhvxOZ29kCdHIrgJPNm4E+2rgwkQRfpR0gnvU=; b=WrtQiZJN9joI1IjQewKQKQQ/1j 2pcxRHyu5YClzXL6OxklaedthoWE6mR/KepGP3Rh09xcwvaVze75d9/qOfBoGha53kIaB/2eEeZLB JRGaqvS80uWPoaBF7z2U5O1z3OoqXVd/dZAlds10StCPBH5oK4uMfN7+0J7ybXuEwX4cTXeCXte8n mO2JNmzSSx8FbItgZXUYrAIeb3ktk4jKHYXFg4mxy1QCZoBR6WzgH4soKlpkyPaWsl56YSwoK4VxQ 06Av/LnOwqiMRbRN06r5ij+FHHWChj2p9hvxBmvYwAQ2ZL9zP5XlW3GEcYbbhqAGvNbDlFXJUBP6c 6nHIqdRQ==; Received: from e0022681537dd.dyn.armlinux.org.uk ([fd8f:7570:feb6:1:222:68ff:fe15:37dd]:55526 helo=rmk-PC.armlinux.org.uk) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vuUu4-00000000430-3vJd; Mon, 23 Feb 2026 12:19:09 +0000 Received: from rmk by rmk-PC.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1vuUu4-0000000Afea-0j9B; Mon, 23 Feb 2026 12:19:08 +0000 From: "Russell King (Oracle)" To: Andrew Lunn Cc: Alexandre Torgue , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , linux-arm-kernel@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, netdev@vger.kernel.org, Paolo Abeni Subject: [PATCH net-next] net: stmmac: fix timestamping configuration after suspend/resume Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Message-Id: Sender: Russell King Date: Mon, 23 Feb 2026 12:19:08 +0000 When stmmac_init_timestamping() is called, it clears the receive and transmit path booleans that allow timestamps to be read. These are never re-initialised until after userspace requests timestamping features to be enabled. However, our copy of the timestamp configuration is not cleared, which means we return the old configuration to userspace when requested. This is inconsistent. Fix this by clearing the timestamp configuration. Signed-off-by: Russell King (Oracle) --- I'm in two minds whether this should go via net or net-next - no one has noticed that getting the timestamp configuration after resume doesn't reflect the hardware state. Here's the commit that introduced the problem: Fixes: d6228b7cdd6e ("net: stmmac: implement the SIOCGHWTSTAMP ioctl") drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 89ded359a9fe..4c127b6b8c08 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -853,6 +853,7 @@ static int stmmac_init_timestamping(struct stmmac_priv *priv) netdev_info(priv->dev, "IEEE 1588-2008 Advanced Timestamp supported\n"); + memset(&priv->tstamp_config, 0, sizeof(priv->tstamp_config)); priv->hwts_tx_en = 0; priv->hwts_rx_en = 0; -- 2.47.3