linux-stable.git/drivers/irqchip, branch linux-6.14.y Linux kernel stable tree irqchip/riscv-imsic: Start local sync timer on correct CPU 2025-05-29T09:13:57+00:00 Andrew Bresticker abrestic@rivosinc.com 2025-05-14T17:13:20+00:00 ef60a8e4fdc22e25721cbe22d89bba9fa953caf2 [ Upstream commit 08fb624802d8786253994d8ebdbbcdaa186f04f5 ] When starting the local sync timer to synchronize the state of a remote CPU it should be added on the CPU to be synchronized, not the initiating CPU. This results in interrupt delivery being delayed until the timer eventually runs (due to another mask/unmask/migrate operation) on the target CPU. Fixes: 0f67911e821c ("irqchip/riscv-imsic: Separate next and previous pointers in IMSIC vector") Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/all/20250514171320.3494917-1-abrestic@rivosinc.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 08fb624802d8786253994d8ebdbbcdaa186f04f5 ]

When starting the local sync timer to synchronize the state of a remote
CPU it should be added on the CPU to be synchronized, not the initiating
CPU. This results in interrupt delivery being delayed until the timer
eventually runs (due to another mask/unmask/migrate operation) on the
target CPU.

Fixes: 0f67911e821c ("irqchip/riscv-imsic: Separate next and previous pointers in IMSIC vector")
Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/all/20250514171320.3494917-1-abrestic@rivosinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
irqchip/riscv-aplic: Add support for hart indexes 2025-05-29T09:13:41+00:00 Vladimir Kondratiev vladimir.kondratiev@mobileye.com 2025-01-29T09:16:37+00:00 d824ac59b8cf5120055b4c7950fedc68ebc402bd [ Upstream commit b93afe8a3ac53ae52296d65acfaa9c5f582a48cc ] RISC-V APLIC specification defines "hart index" in: https://github.com/riscv/riscv-aia Within a given interrupt domain, each of the domain’s harts has a unique index number in the range 0 to 2^14 − 1 (= 16,383). The index number a domain associates with a hart may or may not have any relationship to the unique hart identifier (“hart ID”) that the RISC-V Privileged Architecture assigns to the hart. Two different interrupt domains may employ entirely different index numbers for the same set of harts. Further, this document says in "4.5 Memory-mapped control region for an interrupt domain": The array of IDC structures may include some for potential hart index numbers that are not actual hart index numbers in the domain. For example, the first IDC structure is always for hart index 0, but 0 is not necessarily a valid index number for any hart in the domain. Support arbitrary hart indices specified in an optional APLIC property "riscv,hart-indexes" which is specified as an array of u32 elements, one per interrupt target. If this property is not specified, fallback to use logical hart indices within the domain. Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/all/20250129091637.1667279-3-vladimir.kondratiev@mobileye.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit b93afe8a3ac53ae52296d65acfaa9c5f582a48cc ]

RISC-V APLIC specification defines "hart index" in:

  https://github.com/riscv/riscv-aia

Within a given interrupt domain, each of the domain’s harts has a unique
index number in the range 0 to 2^14 − 1 (= 16,383). The index number a
domain associates with a hart may or may not have any relationship to the
unique hart identifier (“hart ID”) that the RISC-V Privileged Architecture
assigns to the hart. Two different interrupt domains may employ entirely
different index numbers for the same set of harts.

Further, this document says in "4.5 Memory-mapped control region for an
interrupt domain":

The array of IDC structures may include some for potential hart index
numbers that are not actual hart index numbers in the domain. For example,
the first IDC structure is always for hart index 0, but 0 is not
necessarily a valid index number for any hart in the domain.

Support arbitrary hart indices specified in an optional APLIC property
"riscv,hart-indexes" which is specified as an array of u32 elements, one
per interrupt target. If this property is not specified, fallback to use
logical hart indices within the domain.

Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/all/20250129091637.1667279-3-vladimir.kondratiev@mobileye.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
irqchip/riscv-imsic: Set irq_set_affinity() for IMSIC base 2025-05-29T09:13:18+00:00 Andrew Jones ajones@ventanamicro.com 2025-02-17T08:56:47+00:00 77e62be1a8b4dfabe577cd1c75406a05ec5c6458 [ Upstream commit 999f458c1771354371ba367dd84f55f9a62a4233 ] The IMSIC driver assigns the IMSIC domain specific imsic_irq_set_affinity() callback to the per device leaf MSI domain. That's a layering violation as it is called with the leaf domain data and not with the IMSIC domain data. This prevents moving the IMSIC driver to the common MSI library which uses the generic msi_domain_set_affinity() callback for device MSI domains. Instead of using imsic_irq_set_affinity() for leaf MSI domains, use imsic_irq_set_affinity() for the non-leaf IMSIC base domain and use irq_chip_set_affinity_parent() for leaf MSI domains. [ tglx: Massaged change log ] Signed-off-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20250217085657.789309-2-apatel@ventanamicro.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 999f458c1771354371ba367dd84f55f9a62a4233 ]

The IMSIC driver assigns the IMSIC domain specific imsic_irq_set_affinity()
callback to the per device leaf MSI domain. That's a layering violation as
it is called with the leaf domain data and not with the IMSIC domain
data. This prevents moving the IMSIC driver to the common MSI library which
uses the generic msi_domain_set_affinity() callback for device MSI domains.

Instead of using imsic_irq_set_affinity() for leaf MSI domains, use
imsic_irq_set_affinity() for the non-leaf IMSIC base domain and use
irq_chip_set_affinity_parent() for leaf MSI domains.

[ tglx: Massaged change log ]

Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
Signed-off-by: Anup Patel <apatel@ventanamicro.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20250217085657.789309-2-apatel@ventanamicro.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
irqchip/riscv-imsic: Separate next and previous pointers in IMSIC vector 2025-05-29T09:13:15+00:00 Anup Patel apatel@ventanamicro.com 2025-02-17T08:56:53+00:00 dfcabd42a37cbbd046bba7304ea6b99d7aaa7a8c [ Upstream commit 0f67911e821c67ecfccc365a2103ce276a9a56fe ] Currently, there is only one "move" pointer in struct imsic_vector so during vector movement the old vector points to the new vector and new vector points to itself. To support forced cleanup of the old vector, add separate "move_next" and "move_prev" pointers to struct imsic_vector, where during vector movement the "move_next" pointer of the old vector points to the new vector and the "move_prev" pointer of the new vector points to the old vector. Both "move_next" and "move_prev" pointers are cleared separately by __imsic_local_sync() with a restriction that "move_prev" on the new CPU is cleared only after the old CPU has cleared "move_next". Signed-off-by: Anup Patel <apatel@ventanamicro.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20250217085657.789309-8-apatel@ventanamicro.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 0f67911e821c67ecfccc365a2103ce276a9a56fe ]

Currently, there is only one "move" pointer in struct imsic_vector so
during vector movement the old vector points to the new vector and new
vector points to itself.

To support forced cleanup of the old vector, add separate "move_next" and
"move_prev" pointers to struct imsic_vector, where during vector movement
the "move_next" pointer of the old vector points to the new vector and the
"move_prev" pointer of the new vector points to the old vector.

Both "move_next" and "move_prev" pointers are cleared separately by
__imsic_local_sync() with a restriction that "move_prev" on the new
CPU is cleared only after the old CPU has cleared "move_next".

Signed-off-by: Anup Patel <apatel@ventanamicro.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20250217085657.789309-8-apatel@ventanamicro.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs 2025-05-09T07:55:45+00:00 Stephan Gerhold stephan.gerhold@linaro.org 2025-05-02T11:22:28+00:00 d5c10448f411a925dd59005785cb971f0626e032 commit 38a05c0b87833f5b188ae43b428b1f792df2b384 upstream. On Qualcomm chipsets not all GPIOs are wakeup capable. Those GPIOs do not have a corresponding MPM pin and should not be handled inside the MPM driver. The IRQ domain hierarchy is always applied, so it's required to explicitly disconnect the hierarchy for those. The pinctrl-msm driver marks these with GPIO_NO_WAKE_IRQ. qcom-pdc has a check for this, but irq-qcom-mpm is currently missing the check. This is causing crashes when setting up interrupts for non-wake GPIOs: root@rb1:~# gpiomon -c gpiochip1 10 irq: IRQ159: trimming hierarchy from :soc@0:interrupt-controller@f200000-1 Unable to handle kernel paging request at virtual address ffff8000a1dc3820 Hardware name: Qualcomm Technologies, Inc. Robotics RB1 (DT) pc : mpm_set_type+0x80/0xcc lr : mpm_set_type+0x5c/0xcc Call trace: mpm_set_type+0x80/0xcc (P) qcom_mpm_set_type+0x64/0x158 irq_chip_set_type_parent+0x20/0x38 msm_gpio_irq_set_type+0x50/0x530 __irq_set_trigger+0x60/0x184 __setup_irq+0x304/0x6bc request_threaded_irq+0xc8/0x19c edge_detector_setup+0x260/0x364 linereq_create+0x420/0x5a8 gpio_ioctl+0x2d4/0x6c0 Fix this by copying the check for GPIO_NO_WAKE_IRQ from qcom-pdc.c, so that MPM is removed entirely from the hierarchy for non-wake GPIOs. Fixes: a6199bb514d8 ("irqchip: Add Qualcomm MPM controller driver") Reported-by: Alexey Klimov <alexey.klimov@linaro.org> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Alexey Klimov <alexey.klimov@linaro.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20250502-irq-qcom-mpm-fix-no-wake-v1-1-8a1eafcd28d4@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 38a05c0b87833f5b188ae43b428b1f792df2b384 upstream.

On Qualcomm chipsets not all GPIOs are wakeup capable. Those GPIOs do not
have a corresponding MPM pin and should not be handled inside the MPM
driver. The IRQ domain hierarchy is always applied, so it's required to
explicitly disconnect the hierarchy for those. The pinctrl-msm driver marks
these with GPIO_NO_WAKE_IRQ. qcom-pdc has a check for this, but
irq-qcom-mpm is currently missing the check. This is causing crashes when
setting up interrupts for non-wake GPIOs:

 root@rb1:~# gpiomon -c gpiochip1 10
   irq: IRQ159: trimming hierarchy from :soc@0:interrupt-controller@f200000-1
   Unable to handle kernel paging request at virtual address ffff8000a1dc3820
   Hardware name: Qualcomm Technologies, Inc. Robotics RB1 (DT)
   pc : mpm_set_type+0x80/0xcc
   lr : mpm_set_type+0x5c/0xcc
   Call trace:
    mpm_set_type+0x80/0xcc (P)
    qcom_mpm_set_type+0x64/0x158
    irq_chip_set_type_parent+0x20/0x38
    msm_gpio_irq_set_type+0x50/0x530
    __irq_set_trigger+0x60/0x184
    __setup_irq+0x304/0x6bc
    request_threaded_irq+0xc8/0x19c
    edge_detector_setup+0x260/0x364
    linereq_create+0x420/0x5a8
    gpio_ioctl+0x2d4/0x6c0

Fix this by copying the check for GPIO_NO_WAKE_IRQ from qcom-pdc.c, so that
MPM is removed entirely from the hierarchy for non-wake GPIOs.

Fixes: a6199bb514d8 ("irqchip: Add Qualcomm MPM controller driver")
Reported-by: Alexey Klimov <alexey.klimov@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexey Klimov <alexey.klimov@linaro.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20250502-irq-qcom-mpm-fix-no-wake-v1-1-8a1eafcd28d4@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode() 2025-05-02T06:01:48+00:00 Suzuki K Poulose suzuki.poulose@arm.com 2025-04-22T16:16:16+00:00 47bee0081b483b077c7560bc5358ad101f89c8ef commit 3318dc299b072a0511d6dfd8367f3304fb6d9827 upstream. With ACPI in place, gicv2m_get_fwnode() is registered with the pci subsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtime during a PCI host bridge probe. But, the call back is wrongly marked as __init, causing it to be freed, while being registered with the PCI subsystem and could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548 This is easily reproducible on a Juno board with ACPI boot. Retain the function for later use. Fixes: 0644b3daca28 ("irqchip/gic-v2m: acpi: Introducing GICv2m ACPI support") Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 3318dc299b072a0511d6dfd8367f3304fb6d9827 upstream.

With ACPI in place, gicv2m_get_fwnode() is registered with the pci
subsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtime
during a PCI host bridge probe. But, the call back is wrongly marked as
__init, causing it to be freed, while being registered with the PCI
subsystem and could trigger:

 Unable to handle kernel paging request at virtual address ffff8000816c0400
  gicv2m_get_fwnode+0x0/0x58 (P)
  pci_set_bus_msi_domain+0x74/0x88
  pci_register_host_bridge+0x194/0x548

This is easily reproducible on a Juno board with ACPI boot.

Retain the function for later use.

Fixes: 0644b3daca28 ("irqchip/gic-v2m: acpi: Introducing GICv2m ACPI support")
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
irqchip/renesas-rzv2h: Prevent TINT spurious interrupt 2025-05-02T06:01:33+00:00 Biju Das biju.das.jz@bp.renesas.com 2025-04-15T10:33:41+00:00 ff4f09dcfd98436dd2d9f9e635d870e11d1787d6 [ Upstream commit 28e89cdac6482f3c980df3e2e245db7366269124 ] A spurious TINT interrupt is seen during boot on RZ/G3E SMARC EVK. A glitch in the edge detection circuit can cause a spurious interrupt. Clear the status flag after setting the ICU_TSSRk registers, which is recommended in the hardware manual as a countermeasure. Fixes: 0d7605e75ac2 ("irqchip: Add RZ/V2H(P) Interrupt Control Unit (ICU) driver") Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 28e89cdac6482f3c980df3e2e245db7366269124 ]

A spurious TINT interrupt is seen during boot on RZ/G3E SMARC EVK.

A glitch in the edge detection circuit can cause a spurious interrupt.

Clear the status flag after setting the ICU_TSSRk registers, which is
recommended in the hardware manual as a countermeasure.

Fixes: 0d7605e75ac2 ("irqchip: Add RZ/V2H(P) Interrupt Control Unit (ICU) driver")
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
irqchip/renesas-rzv2h: Add struct rzv2h_hw_info with t_offs variable 2025-05-02T06:01:33+00:00 Biju Das biju.das.jz@bp.renesas.com 2025-02-24T13:11:23+00:00 f274e16d1df45a40149f0f55b4d0688d47f6c601 [ Upstream commit 0a9d6ef64e5e917f93db98935cd09bac38507ebf ] The ICU block on the RZ/G3E SoC is almost identical to the one found on the RZ/V2H SoC, with the following differences: - The TINT register base offset is 0x800 instead of zero. - The number of GPIO interrupts for TINT selection is 141 instead of 86. - The pin index and TINT selection index are not in the 1:1 map - The number of TSSR registers is 16 instead of 8 - Each TSSR register can program 2 TINTs instead of 4 TINTs Introduce struct rzv2h_hw_info to describe the SoC properties and refactor the code by moving rzv2h_icu_init() into rzv2h_icu_init_common() and pass the variable containing hw difference to support both these SoCs. As a first step add t_offs to the new struct and replace the hardcoded constants in the code. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Reviewed-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/all/20250224131253.134199-8-biju.das.jz@bp.renesas.com Stable-dep-of: 28e89cdac648 ("irqchip/renesas-rzv2h: Prevent TINT spurious interrupt") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 0a9d6ef64e5e917f93db98935cd09bac38507ebf ]

The ICU block on the RZ/G3E SoC is almost identical to the one found on
the RZ/V2H SoC, with the following differences:

 - The TINT register base offset is 0x800 instead of zero.
 - The number of GPIO interrupts for TINT selection is 141 instead of 86.
 - The pin index and TINT selection index are not in the 1:1 map
 - The number of TSSR registers is 16 instead of 8
 - Each TSSR register can program 2 TINTs instead of 4 TINTs

Introduce struct rzv2h_hw_info to describe the SoC properties and refactor
the code by moving rzv2h_icu_init() into rzv2h_icu_init_common() and pass
the variable containing hw difference to support both these SoCs.

As a first step add t_offs to the new struct and replace the hardcoded
constants in the code.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
Reviewed-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/all/20250224131253.134199-8-biju.das.jz@bp.renesas.com
Stable-dep-of: 28e89cdac648 ("irqchip/renesas-rzv2h: Prevent TINT spurious interrupt")
Signed-off-by: Sasha Levin <sashal@kernel.org>
irqchip/renesas-rzv2h: Simplify rzv2h_icu_init() 2025-05-02T06:01:33+00:00 Biju Das biju.das.jz@bp.renesas.com 2025-02-24T13:11:20+00:00 a1273294515281d840fa206c9f0125764beeaabd [ Upstream commit f5de95438834a3bc3ad747f67c9da93cd08e5008 ] Use devm_add_action_or_reset() for calling put_device in error path of rzv2h_icu_init() to simplify the code by using the recently added devm_* helpers. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/all/20250224131253.134199-5-biju.das.jz@bp.renesas.com Stable-dep-of: 28e89cdac648 ("irqchip/renesas-rzv2h: Prevent TINT spurious interrupt") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit f5de95438834a3bc3ad747f67c9da93cd08e5008 ]

Use devm_add_action_or_reset() for calling put_device in error path of
rzv2h_icu_init() to simplify the code by using the recently added devm_*
helpers.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://lore.kernel.org/all/20250224131253.134199-5-biju.das.jz@bp.renesas.com
Stable-dep-of: 28e89cdac648 ("irqchip/renesas-rzv2h: Prevent TINT spurious interrupt")
Signed-off-by: Sasha Levin <sashal@kernel.org>
irqchip/renesas-rzv2h: Fix wrong variable usage in rzv2h_tint_set_type() 2025-04-20T08:22:54+00:00 Biju Das biju.das.jz@bp.renesas.com 2025-02-24T13:11:18+00:00 9316f3fc3e9a99da52805243c88d7583681d368a commit 72310650788ad3d3afe3810735656dd291fea885 upstream. The variable tssel_n is used for selecting TINT source and titsel_n for setting the interrupt type. The variable titsel_n is wrongly used for enabling the TINT interrupt in rzv2h_tint_set_type(). Fix this issue by using the correct variable tssel_n. While at it, move the tien variable assignment near to tssr. Fixes: 0d7605e75ac2 ("irqchip: Add RZ/V2H(P) Interrupt Control Unit (ICU) driver") Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20250224131253.134199-3-biju.das.jz@bp.renesas.com Closes: https://lore.kernel.org/CAMuHMdU3xJpz-jh=j7t4JreBat2of2ksP_OR3+nKAoZBr4pSxg@mail.gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 72310650788ad3d3afe3810735656dd291fea885 upstream.

The variable tssel_n is used for selecting TINT source and titsel_n for
setting the interrupt type. The variable titsel_n is wrongly used for
enabling the TINT interrupt in rzv2h_tint_set_type(). Fix this issue by
using the correct variable tssel_n.

While at it, move the tien variable assignment near to tssr.

Fixes: 0d7605e75ac2 ("irqchip: Add RZ/V2H(P) Interrupt Control Unit (ICU) driver")
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20250224131253.134199-3-biju.das.jz@bp.renesas.com
Closes: https://lore.kernel.org/CAMuHMdU3xJpz-jh=j7t4JreBat2of2ksP_OR3+nKAoZBr4pSxg@mail.gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>