linux-stable.git/drivers/irqchip, branch v5.9.2

irqchip/ti-sci-intr: Fix unsigned comparison to zero

2020-10-29T09:11:01+00:00

[ Upstream commit 8ddf1905a904ca86d71ca1c435e4b0b2a0b70df8 ]

ti_sci_intr_xlate_irq() return -ENOENT on fail, p_hwirq
should be int type.

Fixes: a5b659bd4bc7 ("irqchip/ti-sci-intr: Add support for INTR being a parent to INTR")
Signed-off-by: YueHaibing 
Signed-off-by: Marc Zyngier 
Acked-by: Lokesh Vutla 
Link: https://lore.kernel.org/r/20200826035321.18620-1-yuehaibing@huawei.com
Signed-off-by: Sasha Levin

irqchip/ti-sci-inta: Fix unsigned comparison to zero

2020-10-29T09:11:01+00:00

[ Upstream commit 4c9b1bfaa5039fee650f4de514a8e70ae976fc2f ]

ti_sci_inta_xlate_irq() return -ENOENT on fail, p_hwirq
should be int type.

Fixes: 5c4b585d2910 ("irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC")
Signed-off-by: YueHaibing 
Signed-off-by: Marc Zyngier 
Acked-by: Lokesh Vutla 
Link: https://lore.kernel.org/r/20200826035430.21060-1-yuehaibing@huawei.com
Signed-off-by: Sasha Levin

Merge tag 'irq-urgent-2020-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2020-08-30T18:56:54+00:00

Pull irq fixes from Thomas Gleixner:
 "A set of fixes for interrupt chip drivers:

   - Revert the platform driver conversion of interrupt chip drivers as
     it turned out to create more problems than it solves.

   - Fix a trivial typo in the new module helpers which made probing
     reliably fail.

   - Small fixes in the STM32 and MIPS Ingenic drivers

   - The TI firmware rework which had badly managed dependencies and had
     to wait post rc1"

* tag 'irq-urgent-2020-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip/ingenic: Leave parent IRQ unmasked on suspend
  irqchip/stm32-exti: Avoid losing interrupts due to clearing pending bits by mistake
  irqchip: Revert modular support for drivers using IRQCHIP_PLATFORM_DRIVER helperse
  irqchip: Fix probing deferal when using IRQCHIP_PLATFORM_DRIVER helpers
  arm64: dts: k3-am65: Update the RM resource types
  arm64: dts: k3-am65: ti-sci-inta/intr: Update to latest bindings
  arm64: dts: k3-j721e: ti-sci-inta/intr: Update to latest bindings
  irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC
  irqchip/ti-sci-inta: Do not store TISCI device id in platform device id field
  dt-bindings: irqchip: Convert ti, sci-inta bindings to yaml
  dt-bindings: irqchip: ti, sci-inta: Update docs to support different parent.
  irqchip/ti-sci-intr: Add support for INTR being a parent to INTR
  dt-bindings: irqchip: Convert ti, sci-intr bindings to yaml
  dt-bindings: irqchip: ti, sci-intr: Update bindings to drop the usage of gic as parent
  firmware: ti_sci: Add support for getting resource with subtype
  firmware: ti_sci: Drop unused structure ti_sci_rm_type_map
  firmware: ti_sci: Drop the device id to resource type translation

irqchip/ingenic: Leave parent IRQ unmasked on suspend

2020-08-25T09:59:29+00:00

All the wakeup sources we possibly want will go through the interrupt
controller, so the parent IRQ must not be masked during suspend, or
there won't be any way to wake up the system.

Signed-off-by: Paul Cercueil 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20200819180602.136969-1-paul@crapouillou.net

irqchip/stm32-exti: Avoid losing interrupts due to clearing pending bits by mistake

2020-08-25T09:57:05+00:00

In the current code, when the eoi callback of the exti clears the pending
bit of the current interrupt, it will first read the values of fpr and
rpr, then logically OR the corresponding bit of the interrupt number,
and finally write back to fpr and rpr.

We found through experiments that if two exti interrupts,
we call them int1/int2, arrive almost at the same time. in our scenario,
the time difference is 30 microseconds, assuming int1 is triggered first.

there will be an extreme scenario: both int's pending bit are set to 1,
the irq handle of int1 is executed first, and eoi handle is then executed,
at this moment, all pending bits are cleared, but the int 2 has not
finally been reported to the cpu yet, which eventually lost int2.

According to stm32's TRM description about rpr and fpr: Writing a 1 to this
bit will trigger a rising edge event on event x, Writing 0 has no
effect.

Therefore, when clearing the pending bit, we only need to clear the
pending bit of the irq.

Fixes: 927abfc4461e7 ("irqchip/stm32: Add stm32mp1 support with hierarchy domain")
Signed-off-by: qiuguorui1 
Signed-off-by: Marc Zyngier 
Cc: stable@vger.kernel.org # v4.18+
Link: https://lore.kernel.org/r/20200820031629.15582-1-qiuguorui1@huawei.com

irqchip: Revert modular support for drivers using IRQCHIP_PLATFORM_DRIVER helperse

2020-08-25T09:48:54+00:00

It has become obvious that switching a number of irqchip drivers
to being platform drivers without considering the platform was a
mistake. We have multiple reports of end-point drivers not
probing because the irqchip driver isn't there yet, breaking
the expectations of the users.

This patch reverts:

920ecb8c35cb ("irqchip/mtk-cirq: Convert to a platform driver")
f97dbf48ca43 ("irqchip/mtk-sysirq: Convert to a platform driver")
5be57099d445 ("irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros")
95bf9305d2e3 ("irqchip/qcom-pdc: Allow QCOM_PDC to be loadable as a permanent module")

and leave QCOM PDC, MTK sysrq and cirq drivers as built-in, special purpose
drivers for the time being until we have worked out a better solution.

Reported-by: Enric Balletbo i Serra 
Reported-by: Frank Wunderlich 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/93debe6a0308b66d3f307af67ba7ec2c@kernel.org

treewide: Use fallthrough pseudo-keyword

2020-08-23T22:36:59+00:00

Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva

irqchip: Fix probing deferal when using IRQCHIP_PLATFORM_DRIVER helpers

2020-08-17T07:06:11+00:00

When probing an interrupt controller that is behind a parent,
we try to check whether the parent domain is available as
an indication that we can actually try to probe.

Unfortunately, we are checking this with the firmware node of
the about to be probed device, not the parent. This is obviously
bound to fail.

Instead, use the parent node.

Fixes: f8410e626569 ("irqchip: Add IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros")
Reported-by: John Stultz 
Tested-by: John Stultz 
Signed-off-by: Marc Zyngier

irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC

2020-08-16T21:01:19+00:00

Driver assumes that Interrupt parent to Interrupt Aggregator is always
Interrupt router. This is not true always and GIC can be a parent to
Interrupt Aggregator. Update the driver to detect the parent and request
the parent irqs accordingly.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20200806074826.24607-11-lokeshvutla@ti.com

irqchip/ti-sci-inta: Do not store TISCI device id in platform device id field

2020-08-16T21:01:19+00:00

Even though DT doesn't make active use of id field in platform_device, we cannot
hijack it to store TISCI device id. So create a field in struct ti_sci_inta
for storing TISCI id and drop usage of id field in platform_device.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20200806074826.24607-10-lokeshvutla@ti.com