linux-stable.git/drivers/irqchip, branch linux-6.11.y

irqchip/irq-mvebu-sei: Move misplaced select() callback to SEI CP domain

2024-12-05T12:54:18+00:00

commit 12aaf67584cf19dc84615b7aba272fe642c35b8b upstream.

Commit fbdf14e90ce4 ("irqchip/irq-mvebu-sei: Switch to MSI parent")
introduced in v6.11-rc1 broke Mavell Armada platforms (and possibly others)
by incorrectly switching irq-mvebu-sei to MSI parent.

In the above commit, msi_parent_ops is set for the sei->cp_domain, but
rather than adding a .select method to mvebu_sei_cp_domain_ops (which is
associated with sei->cp_domain), it was added to mvebu_sei_domain_ops which
is associated with sei->sei_domain, which doesn't have any
msi_parent_ops. This makes the call to msi_lib_irq_domain_select() always
fail.

This bug manifests itself with the following kernel messages on Armada 8040
based systems:

 platform f21e0000.interrupt-controller:interrupt-controller@50: deferred probe pending: (reason unknown)
 platform f41e0000.interrupt-controller:interrupt-controller@50: deferred probe pending: (reason unknown)

Move the select callback to mvebu_sei_cp_domain_ops to cure it.

Fixes: fbdf14e90ce4 ("irqchip/irq-mvebu-sei: Switch to MSI parent")
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Thomas Gleixner 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/E1tE6bh-004CmX-QU@rmk-PC.armlinux.org.uk
Signed-off-by: Greg Kroah-Hartman

irqchip/ocelot: Fix trigger register address

2024-11-17T14:09:50+00:00

[ Upstream commit 9e9c4666abb5bb444dac37e2d7eb5250c8d52a45 ]

Controllers, supported by this driver, have two sets of registers:

 * (main) interrupt registers control peripheral interrupt sources.

 * device interrupt registers configure per-device (network interface)
   interrupts and act as an extra stage before the main interrupt
   registers.

In the driver unmask code, device trigger registers are used in the mask
calculation of the main interrupt sticky register, mixing two kinds of
registers.

Use the main interrupt trigger register instead.

Signed-off-by: Sergey Matsievskiy 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/20240925184416.54204-2-matsievskiysv@gmail.com
Signed-off-by: Sasha Levin

irqchip/gic-v3: Force propagation of the active state with a read-back

2024-11-14T12:21:14+00:00

commit 464cb98f1c07298c4c10e714ae0c36338d18d316 upstream.

Christoffer reports that on some implementations, writing to
GICR_ISACTIVER0 (and similar GICD registers) can race badly with a guest
issuing a deactivation of that interrupt via the system register interface.

There are multiple reasons to this:

 - this uses an early write-acknoledgement memory type (nGnRE), meaning
   that the write may only have made it as far as some interconnect
   by the time the store is considered "done"

 - the GIC itself is allowed to buffer the write until it decides to
   take it into account (as long as it is in finite time)

The effects are that the activation may not have taken effect by the time
the kernel enters the guest, forcing an immediate exit, or that a guest
deactivation occurs before the interrupt is active, doing nothing.

In order to guarantee that the write to the ISACTIVER register has taken
effect, read back from it, forcing the interconnect to propagate the write,
and the GIC to process the write before returning the read.

Reported-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Thomas Gleixner 
Acked-by: Christoffer Dall 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20241106084418.3794612-1-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman

irqchip/renesas-rzg2l: Fix missing put_device

2024-11-01T01:02:29+00:00

[ Upstream commit d038109ac1c6bf619473dda03a16a6de58170f7f ]

rzg2l_irqc_common_init() calls of_find_device_by_node(), but the
corresponding put_device() call is missing.  This also gets reported by
make coccicheck.

Make use of the cleanup interfaces from cleanup.h to call into
__free_put_device(), which in turn calls into put_device when leaving
function rzg2l_irqc_common_init() and variable "dev" goes out of scope.

To prevent that the device is put on successful completion, assign NULL to
"dev" to prevent __free_put_device() from calling into put_device() within
the successful path.

"make coccicheck" will still complain about missing put_device() calls,
but those are false positives now.

Fixes: 3fed09559cd8 ("irqchip: Add RZ/G2L IA55 Interrupt Controller driver")
Signed-off-by: Fabrizio Castro 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/20241011172003.1242841-1-fabrizio.castro.jz@renesas.com
Signed-off-by: Sasha Levin

irqchip/riscv-imsic: Fix output text of base address

2024-11-01T01:02:23+00:00

[ Upstream commit 4a1361e9a5c5dbb5c9f647762ae0cb1a605101fa ]

The "per-CPU IDs ... at base ..." info log is outputting a physical
address, not a PPN.

Fixes: 027e125acdba ("irqchip/riscv-imsic: Add device MSI domain support for platform devices")
Signed-off-by: Andrew Jones 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Anup Patel 
Link: https://lore.kernel.org/all/20240909085610.46625-2-ajones@ventanamicro.com
Signed-off-by: Sasha Levin

irqchip/sifive-plic: Return error code on failure

2024-10-22T13:51:36+00:00

commit 6eabf656048d904d961584de2e1d45bc0854f9fb upstream.

Set error to -ENOMEM if kcalloc() fails or if irq_domain_add_linear()
fails inside of plic_probe() instead of returning 0.

Fixes: 4d936f10ff80 ("irqchip/sifive-plic: Probe plic driver early for Allwinner D1 platform")
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Signed-off-by: Charlie Jenkins 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Anup Patel 
Reviewed-by: Alexandre Ghiti 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20240903-correct_error_codes_sifive_plic-v1-1-d929b79663a2@rivosinc.com
Closes: https://lore.kernel.org/r/202409031122.yBh8HrxA-lkp@intel.com/
Signed-off-by: Greg Kroah-Hartman

irqchip/sifive-plic: Unmask interrupt in plic_irq_enable()

2024-10-22T13:51:36+00:00

commit 6b1e0651e9ce8ce418ad4ff360e7b9925dc5da79 upstream.

It is possible that an interrupt is disabled and masked at the same time.
When the interrupt is enabled again by enable_irq(), only plic_irq_enable()
is called, not plic_irq_unmask(). The interrupt remains masked and never
raises.

An example where interrupt is both disabled and masked is when
handle_fasteoi_irq() is the handler, and IRQS_ONESHOT is set. The interrupt
handler:

  1. Mask the interrupt
  2. Handle the interrupt
  3. Check if interrupt is still enabled, and unmask it (see
     cond_unmask_eoi_irq())

If another task disables the interrupt in the middle of the above steps,
the interrupt will not get unmasked, and will remain masked when it is
enabled in the future.

The problem is occasionally observed when PREEMPT_RT is enabled, because
PREEMPT_RT adds the IRQS_ONESHOT flag. But PREEMPT_RT only makes the problem
more likely to appear, the bug has been around since commit a1706a1c5062
("irqchip/sifive-plic: Separate the enable and mask operations").

Fix it by unmasking interrupt in plic_irq_enable().

Fixes: a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask operations")
Signed-off-by: Nam Cao 
Signed-off-by: Thomas Gleixner 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20241003084152.2422969-1-namcao@linutronix.de
Signed-off-by: Greg Kroah-Hartman

irqchip/gic-v4: Don't allow a VMOVP on a dying VPE

2024-10-22T13:51:36+00:00

commit 1442ee0011983f0c5c4b92380e6853afb513841a upstream.

Kunkun Jiang reported that there is a small window of opportunity for
userspace to force a change of affinity for a VPE while the VPE has already
been unmapped, but the corresponding doorbell interrupt still visible in
/proc/irq/.

Plug the race by checking the value of vmapp_count, which tracks whether
the VPE is mapped ot not, and returning an error in this case.

This involves making vmapp_count common to both GICv4.1 and its v4.0
ancestor.

Fixes: 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP")
Reported-by: Kunkun Jiang 
Signed-off-by: Marc Zyngier 
Signed-off-by: Thomas Gleixner 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/c182ece6-2ba0-ce4f-3404-dba7a3ab6c52@huawei.com
Link: https://lore.kernel.org/all/20241002204959.2051709-1-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman

irqchip/irq-msi-lib: Check for NULL ops in msi_lib_irq_domain_select()

2024-08-23T11:55:15+00:00

The irq_domain passed to msi_lib_irq_domain_select() may not have
msi_parent_ops set. There is a NULL pointer check for it, but unfortunately
there is a dereference of the parent ops pointer before that.

Move the NULL pointer test before the first use of that pointer.

This was found on a MacchiatoBin (Marvell Armada 8K SoC), which uses the
irq-mvebu-sei driver.

Fixes: 72e257c6f058 ("irqchip: Provide irq-msi-lib")
Signed-off-by: Maxime Chevallier 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/all/20240823100733.1900666-1-maxime.chevallier@bootlin.com
Closes: https://lore.kernel.org/all/20240821165034.1af97bad@fedora-3.home/

irqchip/gic-v3: Init SRE before poking sysregs

2024-08-23T10:45:45+00:00

The GICv3 driver pokes GICv3 system registers in gic_prio_init() before
gic_cpu_sys_reg_init() ensures that GICv3 system registers have been
enabled by writing to ICC_SRE_EL1.SRE.

On arm64 this is benign as has_useable_gicv3_cpuif() runs earlier during
cpufeature detection, and this enables the GICv3 system registers.

On 32-bit arm when booting on an FVP using the boot-wrapper, the accesses
in gic_prio_init() end up being UNDEFINED and crashes the kernel during
boot.

This is a regression introduced by the addition of gic_prio_init().

Fix this by factoring out the SRE initialization into a new function and
calling it early in the three paths where SRE may not have been
initialized:

(1) gic_init_bases(), before the primary CPU pokes GICv3 sysregs in
    gic_prio_init().

(2) gic_starting_cpu(), before secondary CPUs initialize GICv3 sysregs
    in gic_cpu_init().

(3) gic_cpu_pm_notifier(), before CPUs re-initialize GICv3 sysregs in
    gic_cpu_sys_reg_init().

Fixes: d447bf09a4013541 ("irqchip/gic-v3: Detect GICD_CTRL.DS and SCR_EL3.FIQ earlier")
Signed-off-by: Mark Rutland 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Marc Zyngier 
Cc: stable@vger.kernel.org