From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.153.233]) (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 278264E9C20; Fri, 18 Sep 2026 11:34:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=68.232.153.233 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789731286; cv=none; b=J0mI7XVnbvTxb315QKNN4LBI5pmz3r0WDDk55qqjrDTnkZhK1CKaRALc5LqEI7ZCMKr0fQ5udg2QlWb89NMoDNrk9Soyw4BBbTrfIEqRve7l7GuKLwyVuge6eKHIGCJo4xgOZl6ylIcIUNOk6RrtBePVydlVjFsMumIwsSvGNIU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789731286; c=relaxed/simple; bh=rVpMMDlK7E+NlpQ9MahYaWBp6KhJAh4OQm2tWvl9qOI=; h=From:Date:Subject:MIME-Version:Content-Type:Message-ID:References: In-Reply-To:To:CC; b=KlePS/i1BxJ6hzbqRD0Q6Yoytt4T69n0xW/M0Z0V1d2MNDVIBuCoM75Cw+kwqITeNTKVxJzpEXT/rSFea50ryOATb4jouVDF091dbdQqyoSRpDlKCCbc+RkyzDSIabt1uAAuoZzRTYvqiKlKS/eMeNrsxCv3D9k+SZBgXam+J6Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=microchip.com; spf=pass smtp.mailfrom=microchip.com; dkim=pass (2048-bit key) header.d=microchip.com header.i=@microchip.com header.b=IYbWW/dd; arc=none smtp.client-ip=68.232.153.233 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=microchip.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=microchip.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=microchip.com header.i=@microchip.com header.b="IYbWW/dd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1789731285; x=1821267285; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=rVpMMDlK7E+NlpQ9MahYaWBp6KhJAh4OQm2tWvl9qOI=; b=IYbWW/dd8MyRIvRyFMlXRhbK2fi3Zmu2/zH6YbazNcV7HtQfkLBpxo3f 2x4fZBmLWFDC41KtWapERovWz0MvAQ+OkReKOnQ2OXgKRTuXhJR/FZhro TNRXOSDx7e5ry9jXuSzMUrw8oknFhwjwwBANK49NLmMmXtVY0H6GWQYMr kfIIV6fGQgbeF8vErYyLt/gSnJAwtC9faW5F1nZM7964uU5U9b5Q0qoYI UonTCcYq8CcSbl8ISjck8F/M+JvDblJck7q5Ms8y/LeS8OcCgLfjczB3a 5fTVmUV7fCTzRJ6x99ns48i8nlro1/nssZeupFfSuw3DXaaBW5MOcRq9p A==; X-CSE-ConnectionGUID: iVJHd0nWRKCxmVKcpc8qdg== X-CSE-MsgGUID: wMYJoxRlTLGjgraOvSG/wA== X-IronPort-AV: E=Sophos;i="6.27,108,1787036400"; d="scan'208";a="295223735" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa5.microchip.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 18 Sep 2026 04:34:44 -0700 Received: from chn-vm-ex04.mchp-main.com (10.10.85.152) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.58; Fri, 18 Sep 2026 04:34:43 -0700 Received: from DEN-DL-M70577.microsemi.net (10.10.85.11) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server id 15.1.2507.58 via Frontend Transport; Fri, 18 Sep 2026 04:34:39 -0700 From: Daniel Machon Date: Fri, 18 Sep 2026 13:34:00 +0200 Subject: [PATCH net-next v7 08/14] net: lan966x: clear FDMA interrupt stickies after switch reset Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <20260918-lan966x-pci-fdma-v7-8-0ecc179c8a2c@microchip.com> References: <20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c@microchip.com> In-Reply-To: <20260918-lan966x-pci-fdma-v7-0-0ecc179c8a2c@microchip.com> To: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Horatiu Vultur , Steen Hegelund , , "Alexei Starovoitov" , Daniel Borkmann , "Jesper Dangaard Brouer" , John Fastabend , Stanislav Fomichev , Herve Codina , Arnd Bergmann , Greg Kroah-Hartman , Mohsin Bashir CC: Richard Cochran , , , , X-Mailer: b4 0.14.3 When in PCI mode, the GCB soft reset issued by the reset controller can latch spurious bits in the FDMA error stickies. The latched bits sit in FDMA_INTR_ERR until the FDMA IRQ is requested later in probe, at which point the handler fires immediately and WARNs. Clear FDMA_ERRORS, FDMA_INTR_ERR and FDMA_INTR_DB right after the switch reset so the FDMA comes out clean and the IRQ handler does not see ghost errors on probe. The clear runs on both the PCI and platform paths. On the platform path it has no effect — there are no spurious stickies to clear — but keeping it unconditional avoids a PCI-specific code path here. Tested-by: Herve Codina Signed-off-by: Daniel Machon --- drivers/net/ethernet/microchip/lan966x/lan966x_main.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c index 6e6c08bb8eea..11094a381ec2 100644 --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c @@ -1067,6 +1067,15 @@ static int lan966x_reset_switch(struct lan966x *lan966x) reset_control_reset(switch_reset); + /* When in PCI mode, the GCB soft reset issued by the reset + * controller can latch spurious bits in the FDMA error stickies. + * Clear them before request_irq hooks up the FDMA IRQ line, + * otherwise the handler fires immediately on probe. + */ + lan_wr(lan_rd(lan966x, FDMA_ERRORS), lan966x, FDMA_ERRORS); + lan_wr(lan_rd(lan966x, FDMA_INTR_ERR), lan966x, FDMA_INTR_ERR); + lan_wr(lan_rd(lan966x, FDMA_INTR_DB), lan966x, FDMA_INTR_DB); + /* Don't reinitialize the switch core, if it is already initialized. In * case it is initialized twice, some pointers inside the queue system * in HW will get corrupted and then after a while the queue system gets -- 2.34.1