From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 16826407CDA; Tue, 21 Jul 2026 22:14:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784672067; cv=none; b=kh5dPfoL8hdDGcCOv8mbfFR/4MNWUOBKf9gpKBlim7xYUkyE8C5X0z2ZTHMrSV10udGzlJnbTICaeLheaLkBy3fpDahbC2SCFnnHls6XnWlkQw7QR8puz1fXpRWJvSA73wUuusnL652a3Tzs5rfFAroqCYE4qctQip83XvYlglY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784672067; c=relaxed/simple; bh=Z5QZ9PSzBvS9EzERb1sdIP6G74QhoQW6R8AOCVyMdRo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XfNA+i0LDNaGTCti56CPq7e/IBJ+bXpX2GbMfnwmvbA4Xhx5vMjkBhbPrSL3q03zGrx/oQ40rBOtMWi8ULPTt04chlnocERLJjv2+sl2SD0O4sGL/1Zj1twAe19+Bp1dgejtWMQlxBswNIN+VhiZy1wi0AyS5rmGfgpRNpsEh60= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=UEK7mdzX; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="UEK7mdzX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7CEF81F000E9; Tue, 21 Jul 2026 22:14:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1784672066; bh=Nx7M3gBm7kCaRvTiWirIB2s5jNCYL6IpDXIpRW0A6m8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=UEK7mdzXqtZihTVN2iFHt9fCBWOC8BN8cvU/mxxviMo+2irT9QGWR2amnaELisIBL uWwy+bai75aEShHGXpvDvNecYfklNbpl1EmqiMgVT5aXV7BMqgZC4/p3Mllm3O6yXA OIZJKgowJGZ0CL24v/dQgAYd+CGuTpbhxUGWpOqk= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Yun Zhou , Sebastian Andrzej Siewior , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.15 483/843] net: mvneta: re-enable percpu interrupt on resume Date: Tue, 21 Jul 2026 17:21:58 +0200 Message-ID: <20260721152416.897447821@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260721152405.946368001@linuxfoundation.org> References: <20260721152405.946368001@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Yun Zhou [ Upstream commit fd398d6480987e4c84fff0aaab6b9d6642a93343 ] On Marvell MPIC platforms (Armada 370/XP/38x), mvneta uses a percpu IRQ disable/enable scheme for NAPI: the ISR (mvneta_percpu_isr) calls disable_percpu_irq() to mask the MPIC per-CPU interrupt and schedules NAPI poll, which calls enable_percpu_irq() on completion to unmask. If suspend occurs while NAPI poll is pending (between disable_percpu_irq in the ISR and enable_percpu_irq in poll completion), the interrupt is never re-enabled: 1. mvneta_percpu_isr: disable_percpu_irq() + napi_schedule() => MPIC masked, percpu_enabled cpumask bit cleared 2. NAPI poll does not complete before suspend proceeds (on PREEMPT_RT this is highly likely since softirqs run in ksoftirqd which gets frozen; on non-RT it can happen when softirq processing is deferred to ksoftirqd) 3. mvneta_stop_dev => napi_disable(): cancels the pending poll without executing the completion path 4. suspend_device_irqs => IRQCHIP_MASK_ON_SUSPEND: masks MPIC (already masked, but records IRQS_SUSPENDED) 5. Resume: mpic_resume checks irq_percpu_is_enabled() => false (bit was cleared in step 1) => skips unmask 6. mvneta_start_dev only restores device-level INTR_NEW_MASK, does not touch the MPIC per-CPU mask Result: MPIC per-CPU interrupt stays masked permanently. The NIC generates interrupts (INTR_NEW_CAUSE != 0) but the CPU never receives them, causing complete loss of network connectivity. Fix by calling on_each_cpu(mvneta_percpu_enable) in the resume path to unconditionally unmask the MPIC per-CPU interrupt regardless of pre-suspend state. Fixes: 12bb03b436da ("net: mvneta: Handle per-cpu interrupts") Signed-off-by: Yun Zhou Reviewed-by: Sebastian Andrzej Siewior Link: https://patch.msgid.link/20260622074350.1666290-1-yun.zhou@windriver.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- drivers/net/ethernet/marvell/mvneta.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c index 3f124268bd4d4b..269d5c8e2b0964 100644 --- a/drivers/net/ethernet/marvell/mvneta.c +++ b/drivers/net/ethernet/marvell/mvneta.c @@ -5517,6 +5517,9 @@ static int mvneta_resume(struct device *device) rtnl_unlock(); mvneta_set_rx_mode(dev); + if (!pp->neta_armada3700) + on_each_cpu(mvneta_percpu_enable, pp, true); + return 0; } #endif -- 2.53.0