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 AC14343849F; Tue, 21 Jul 2026 21:34:34 +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=1784669676; cv=none; b=rFZuBsySgZELIIYZzkFlrHwuQjfvbBUF8eul6MDKSbxNdV/vc73JKeTMEEx4oydYS7b0hTKpeFeQEKxW1/3vKvBusTsmh6MBEK9kXqo44W0Vy3OprAqOe0baoBe9QvwelQLwH3IeNEOpM3zAM51uVXbbIDCp2YryMi53ymrHFNc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784669676; c=relaxed/simple; bh=umBILamPwmGRThHlFdkKn/BRGCq9r3jgISd1BG7lmF8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=H+dI24A7ngIbMfj3l4Pkrr/NKPSu37f6aIalV2swPCgz8UmAJ2fP9aqybWAdl61XhJ/RIdhbY60PDtxuo/x7o5k9+6pmn8XyA02pEc4UpmK/dzyJ9FwplbqD8bKP7UTPW6yY9HWHbi6gskZ5TTazzcB9hsGSrY8jBAXcrHhcCqA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=gD/4Yeh4; 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="gD/4Yeh4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98DDE1F000E9; Tue, 21 Jul 2026 21:34:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1784669674; bh=ibyJk1JHhWJZ4/D2SJpAO8jiBLzPLAiyvsVcX6f/XXA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=gD/4Yeh49CQG9uTXcQhuZtpOYTZfNuYQGURShe7tv854P7d7+nYKZvTxjOQkZEZGY r3EM3Mi5isJ812UiR+FTbPJZpqYuRS+orbZdHzkJhE3nl4AhWPolIL1HVPAbSbVCGQ abHND5HRVIalNNubFvX8h08ZEOHuXSQcIAj1Q8u4= 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 6.1 0643/1067] net: mvneta: re-enable percpu interrupt on resume Date: Tue, 21 Jul 2026 17:20:44 +0200 Message-ID: <20260721152438.978363662@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260721152424.521567757@linuxfoundation.org> References: <20260721152424.521567757@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 6.1-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 eb4ebaa1c92ff7..1faf3dbd9233e2 100644 --- a/drivers/net/ethernet/marvell/mvneta.c +++ b/drivers/net/ethernet/marvell/mvneta.c @@ -5799,6 +5799,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