Skip to contentSkip to conversation

Patch "genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs" has been added to the 4.9-stable tree

PATCH [email protected] 1 participant 1 message Mar 22, 2018

Subsystems (2)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs

to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch
and it can be found in the queue-4.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From foo@baz Thu Mar 22 14:40:23 CET 2018

From: Hans de Goede <[email protected]>
Date: Sat, 15 Apr 2017 12:08:31 +0200
Subject: genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs

From: Hans de Goede <[email protected]>

[ Upstream commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 ]

When requesting a shared irq with IRQF_TRIGGER_NONE then the irqaction flags get filled with the trigger type from the irq_data:

        if (!(new->flags & IRQF_TRIGGER_MASK))
                new->flags |= irqd_get_trigger_type(&desc->irq_data);

On the first setup_irq() the trigger type in irq_data is NONE when the above code executes, then the irq is started up for the first time and then the actual trigger type gets established, but that's too late to fix up new->flags.

When then a second user of the irq requests the irq with IRQF_TRIGGER_NONE its irqaction's triggertype gets set to the actual trigger type and the following check fails:

        if (!((old->flags ^ new->flags) & IRQF_TRIGGER_MASK))

Resulting in the request_irq failing with -EBUSY even though both users requested the irq with IRQF_SHARED | IRQF_TRIGGER_NONE

Fix this by comparing the new irqaction's trigger type to the trigger type stored in the irq_data which correctly reflects the actual trigger type being used for the irq.

---
 kernel/irq/manage.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
kernel/irq/manage.c +3 -1
@@ -1210,8 +1210,10 @@ __setup_irq(unsigned int irq, struct irq
 		 * set the trigger type must match. Also all must
 		 * agree on ONESHOT.
 		 */
+		unsigned int oldtype = irqd_get_trigger_type(&desc->irq_data);
+
 		if (!((old->flags & new->flags) & IRQF_SHARED) ||
-		    ((old->flags ^ new->flags) & IRQF_TRIGGER_MASK) ||
+		    (oldtype != (new->flags & IRQF_TRIGGER_MASK)) ||
 		    ((old->flags ^ new->flags) & IRQF_ONESHOT))
 			goto mismatch;
 

Patches currently in stable-queue which might be from [email protected] are

queue-4.9/power-supply-bq24190_charger-limit-over-under-voltage-fault-logging.patch queue-4.9/acpi-pmic-xpower-fix-power_table-addresses.patch queue-4.9/acpi-power-delay-turning-off-unused-power-resources-after-suspend.patch queue-4.9/rtc-cmos-do-not-assume-irq-8-for-rtc-when-there-are-no-legacy-irqs.patch queue-4.9/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch queue-4.9/power-supply-bq24190_charger-add-disable-reset-device-property.patch queue-4.9/x86-i8259-export-legacy_pic-symbol.patch