[RFC PATCH 06/10] genirq: Don't mask IRQ within flow handler if IRQ is flow-masked
Valentin Schneider
valentin.schneider at arm.com
Thu Apr 8 16:43:22 BST 2021
mask_irq() lets an IRQ with IRQD_IRQ_FLOW_MASKED set be further masked via
chip->irq_mask(). This is necessary for unhandled IRQs as we want to keep
them masked beyond eoi_irq() (which clears IRQD_IRQ_FLOW_MASKED).
This is however not necessary in paths that do end up handling the IRQ and
are bounded by a final eoi_irq() - this is the case for chips with
IRQCHIP_AUTOMASKS_FLOW and IRQCHIP_EOI_THREADED.
Make handle_strict_flow_irq() leverage IRQCHIP_AUTOMASKS_FLOW and issue an
ack_irq() rather than a mask_ack_irq() when possible.
Signed-off-by: Valentin Schneider <valentin.schneider at arm.com>
---
kernel/irq/chip.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6c033b0044cb..1add0b4f0662 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -909,10 +909,9 @@ void handle_strict_flow_irq(struct irq_desc *desc)
struct irq_chip *chip = desc->irq_data.chip;
raw_spin_lock(&desc->lock);
- mask_ack_irq(desc);
if (!irq_may_run(desc))
- goto out;
+ goto out_mask;
desc->istate &= ~(IRQS_REPLAY | IRQS_WAITING);
@@ -922,10 +921,21 @@ void handle_strict_flow_irq(struct irq_desc *desc)
*/
if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) {
desc->istate |= IRQS_PENDING;
- goto out;
+ goto out_mask;
}
kstat_incr_irqs_this_cpu(desc);
+ /*
+ * Masking is required if IRQ is ONESHOT and we can't rely on the
+ * flow-masking persisting down to irq_finalize_oneshot()
+ * (in the IRQ thread).
+ */
+ if ((desc->istate & IRQS_ONESHOT) &&
+ (!(chip->flags & IRQCHIP_AUTOMASKS_FLOW) ||
+ !(chip->flags & IRQCHIP_EOI_THREADED)))
+ mask_ack_irq(desc);
+ else
+ ack_irq(desc);
handle_irq_event(desc);
@@ -933,7 +943,8 @@ void handle_strict_flow_irq(struct irq_desc *desc)
raw_spin_unlock(&desc->lock);
return;
-out:
+out_mask:
+ mask_ack_irq(desc);
/*
* XXX: this is where IRQCHIP_EOI_IF_HANDLED would be checked, but
* it's conceptually incompatible with this handler (it breaks the
--
2.25.1
More information about the linux-arm-kernel
mailing list