From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) (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 E12623E0221; Mon, 4 May 2026 14:24:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=68.232.154.123 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777904644; cv=none; b=c9WMbdfVdgvvyV2bwXukuniyqBOd45izEPxpx9azF3HgFa9TyL0TUPanbkFBkhKfgKQ5/tZzJnBmKCptzw2egGguhKjDRWoWuMDDfO2wJ2hndiBbmSxixzn1Qow8x0S5Y7+A7Cw5IRgqNWUwZZK8bNkJfKE8bRbhF8lj4S/rivs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777904644; c=relaxed/simple; bh=aEVxBzQijPj9PRsFyC76Lsq/Pj8h04R9UN1sWdxuvLM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-ID:References: In-Reply-To:To:CC; b=G7By9lapmCFfbY7G4bDINqVzIi90pRGjsIITZ0hIa+vSF6YCaJ44gaS4bAFHodwuKOJ8J0hC671M+RnHpNA2EnTSvwxwhCzNRqHFyLHCzlBaP40R9nnYCHJnChEj10dhIPGMV2ESBtIjo6o1s96UBlQUSL1fp5/l1cO2LavYEtA= 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=VE3H0hXq; arc=none smtp.client-ip=68.232.154.123 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="VE3H0hXq" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1777904643; x=1809440643; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=aEVxBzQijPj9PRsFyC76Lsq/Pj8h04R9UN1sWdxuvLM=; b=VE3H0hXqls3i/u71l6AHZh+zUgFZ+kkCMPqpF1tT4ov4BpB3S24L3Hrc t9rrKIAFp64Vskm+3kbhT4hF/miZnMNdKN5mMLg/iNkEF280r5OZo4bhM gbP48sq2udv1EA+S5UyfnJ/s6QWQvAOXXZMS35t5TLiLp74npW8c+VEqm 340OUefaNOtoz8lK6zyJQkaBztb0UTY7PW40lyoqSHCIanR4ViXZKyaoF CoOOXyuqfrVSd7EInrwErVLQ4WrWnQ4mBGSmjwGsVbEc+irVhyV/gYRU9 cr77TlTFzGviJyIHeWYJx6FnOjpRO9+zHQP4HxMn/RVkLI1/X4AnMMf2L Q==; X-CSE-ConnectionGUID: hACnvN32QBaW+0zejO9F1Q== X-CSE-MsgGUID: euxtG5IaTue3umCyfPHN0w== X-IronPort-AV: E=Sophos;i="6.23,215,1770620400"; d="scan'208";a="57408616" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa2.microchip.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 04 May 2026 07:24:02 -0700 Received: from chn-vm-ex01.mchp-main.com (10.10.85.143) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.58; Mon, 4 May 2026 07:24:01 -0700 Received: from DEN-DL-M70577.microsemi.net (10.10.85.11) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server id 15.1.2507.58 via Frontend Transport; Mon, 4 May 2026 07:23:58 -0700 From: Daniel Machon Date: Mon, 4 May 2026 16:23:20 +0200 Subject: [PATCH net-next v3 07/13] 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: <20260504-lan966x-pci-fdma-v3-7-a56f5740d870@microchip.com> References: <20260504-lan966x-pci-fdma-v3-0-a56f5740d870@microchip.com> In-Reply-To: <20260504-lan966x-pci-fdma-v3-0-a56f5740d870@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: , , , 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 9f69634ebb0a..b3701953b090 100644 --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c @@ -1064,6 +1064,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