mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Markus Stockhausen <markus.stockhausen@gmx.de>,
	Sebastian Gottschall <s.gottschall@dd-wrt.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Sasha Levin <sashal@kernel.org>,
	tsbogend@alpha.franken.de, linux-mips@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.16 67/85] irqchip/mips-gic: Allow forced affinity
Date: Sun,  3 Aug 2025 20:23:16 -0400	[thread overview]
Message-ID: <20250804002335.3613254-67-sashal@kernel.org> (raw)
In-Reply-To: <20250804002335.3613254-1-sashal@kernel.org>

From: Markus Stockhausen <markus.stockhausen@gmx.de>

[ Upstream commit 2250db8628a0d8293ad2e0671138b848a185fba1 ]

Devices of the Realtek MIPS Otto platform use the official rtl-otto-timer
as clock event generator and CPU clocksource. It is registered for each CPU
startup via cpuhp_setup_state() and forces the affinity of the clockevent
interrupts to the appropriate CPU via irq_force_affinity().

On the "smaller" devices with a vendor specific interrupt controller
(supported by irq-realtek-rtl) the registration works fine. The "larger"
RTL931x series is based on a MIPS interAptiv dual core with a MIPS GIC
controller. Interrupt routing setup is cancelled because gic_set_affinity()
does not accept the current (not yet online) CPU as a target.

Relax the checks by evaluating the force parameter that is provided for
exactly this purpose like in other drivers. With this the affinity can be
set as follows:

 - force = false: allow to set affinity to any online cpu
 - force = true:  allow to set affinity to any cpu

Co-developed-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20250621054952.380374-1-markus.stockhausen@gmx.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my analysis of the commit, here is my assessment:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the
following reasons:

1. **Fixes a real bug affecting users**: The commit fixes a specific
   issue where clockevent interrupt affinity setup fails on Realtek
   RTL931x devices with MIPS GIC controllers. Without this fix, the
   timer registration during CPU hotplug fails because
   `gic_set_affinity()` rejects setting affinity to CPUs that are not
   yet online.

2. **Small and contained fix**: The change is minimal - it only adds 4
   lines of code to properly handle the `force` parameter that was
   already being passed but ignored. The logic change is
   straightforward:
   - When `force=false`: Use existing behavior (only allow online CPUs)
   - When `force=true`: Allow any CPU in the mask

3. **Follows established patterns**: The commit shows that multiple
   other timer drivers (`timer-rtl-otto.c`, `timer-tegra.c`,
   `exynos_mct.c`, etc.) use `irq_force_affinity()` during CPU hotplug,
   which eventually calls the chip's `set_affinity` handler with
   `force=true`. The MIPS GIC driver was incorrectly ignoring this
   parameter.

4. **No architectural changes**: This is purely a bug fix that makes the
   MIPS GIC driver honor the existing `force` parameter semantics. It
   doesn't introduce new features or change any architecture.

5. **Clear use case**: The commit message clearly explains that this
   affects real hardware (Realtek RTL931x series) and prevents proper
   timer initialization during CPU hotplug, which is a fundamental
   kernel operation.

6. **Low regression risk**: The change only affects behavior when
   `force=true` is explicitly passed, which is specifically for CPU
   hotplug scenarios. Normal interrupt affinity operations (with
   `force=false`) remain unchanged.

7. **Aligns with kernel conventions**: The kernel documentation for
   `irq_force_affinity()` explicitly states it's "Solely for low level
   cpu hotplug code, where we need to make per cpu interrupts affine
   before the cpu becomes online." This commit makes the MIPS GIC driver
   comply with this intended behavior.

The fix is essential for proper operation of affected hardware and
follows the stable kernel criteria of being a important bugfix with
minimal risk.

 drivers/irqchip/irq-mips-gic.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips-gic.c
index 34e8d09c12a0..19a57c5e2b2e 100644
--- a/drivers/irqchip/irq-mips-gic.c
+++ b/drivers/irqchip/irq-mips-gic.c
@@ -375,9 +375,13 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *cpumask,
 	/*
 	 * The GIC specifies that we can only route an interrupt to one VP(E),
 	 * ie. CPU in Linux parlance, at a time. Therefore we always route to
-	 * the first online CPU in the mask.
+	 * the first forced or online CPU in the mask.
 	 */
-	cpu = cpumask_first_and(cpumask, cpu_online_mask);
+	if (force)
+		cpu = cpumask_first(cpumask);
+	else
+		cpu = cpumask_first_and(cpumask, cpu_online_mask);
+
 	if (cpu >= NR_CPUS)
 		return -EINVAL;
 
-- 
2.39.5


      parent reply	other threads:[~2025-08-04  0:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250804002335.3613254-1-sashal@kernel.org>
2025-08-04  0:22 ` [PATCH AUTOSEL 6.16 09/85] regulator: core: repeat voltage setting request for stepped regulators Sasha Levin
2025-08-04 11:36   ` Mark Brown
2025-08-16 13:09     ` Sasha Levin
2025-08-04  0:22 ` [PATCH AUTOSEL 6.16 18/85] binder: Fix selftest page indexing Sasha Levin
2025-08-04  0:22 ` [PATCH AUTOSEL 6.16 49/85] irqchip/renesas-rzv2h: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND Sasha Levin
2025-08-04  0:22 ` [PATCH AUTOSEL 6.16 50/85] selftests: vDSO: vdso_test_getrandom: Always print TAP header Sasha Levin
2025-08-04  0:23 ` [PATCH AUTOSEL 6.16 56/85] mei: bus: Check for still connected devices in mei_cl_bus_dev_release() Sasha Levin
2025-08-04  0:23 ` Sasha Levin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250804002335.3613254-67-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=markus.stockhausen@gmx.de \
    --cc=patches@lists.linux.dev \
    --cc=s.gottschall@dd-wrt.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®