irqchip: gic: always mask interrupts during suspend

The core kernel IRQ code will disable all non-wakeup interrupts before suspend, but because the GIC uses lazy masking (i.e., it doesn't mask interrupts, but only disables them logically), we still might be processing interrupts after the last call for interrupts (check_wakeup_irqs()). This can cause various problems, so let's just always mask our interrupts before suspend.

Several platforms already tweak the GIC irqchip flags to do this (and I'm working on bringing up another platform that needs this), so let's just set IRQCHIP_MASK_ON_SUSPEND by default.

---
This is just an RFC. If it is acceptable, I'll need to break it up for application to each sub-arch tree.

I really don't like the gic_arch_extn approach to customizing the GIC driver, so I thought this was one opportunity to unify some platform code. If this approach isn't accpetable, I can simply add this flag to my own machine init code. But I thought this was a good starting place for discussion about this odd piece of code.

Other random thought: it seems like any irqchip driver which does lazy IRQ masking ought to use IRQCHIP_MASK_ON_SUSPEND. So maybe the IRQ core should just do something like:

	if (!chip->irq_disable)
		chip->flags |= IRQCHIP_MASK_ON_SUSPEND;

 arch/arm/mach-omap2/omap-wakeupgen.c | 2 +-
 arch/arm/mach-tegra/irq.c            | 1 -
 arch/arm/mach-ux500/cpu.c            | 2 +-
 arch/arm/mach-zynq/common.c          | 2 +-
 drivers/irqchip/irq-gic.c            | 1 +
 5 files changed, 4 insertions(+), 4 deletions(-)

index 37843a7d3639..c9c12ea6dd09 100644
@@ -440,7 +440,7 @@ int __init omap_wakeupgen_init(void)
 	 */
 	gic_arch_extn.irq_mask = wakeupgen_mask;
 	gic_arch_extn.irq_unmask = wakeupgen_unmask;
-	gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_SKIP_SET_WAKE;
+	gic_arch_extn.flags = IRQCHIP_SKIP_SET_WAKE;
 
 	/*
 	 * FIXME: Add support to set_smp_affinity() once the core

index 1a74d562dca1..6f0529021520 100644
@@ -281,7 +281,6 @@ void __init tegra_init_irq(void)
 	gic_arch_extn.irq_unmask = tegra_unmask;
 	gic_arch_extn.irq_retrigger = tegra_retrigger;
 	gic_arch_extn.irq_set_wake = tegra_set_wake;
-	gic_arch_extn.flags = IRQCHIP_MASK_ON_SUSPEND;
 
 	/*
 	 * Check if there is a devicetree present, since the GIC will be

index db16b5a04ad5..ce2bfe39dd82 100644
@@ -52,7 +52,7 @@ void ux500_restart(enum reboot_mode mode, const char *cmd)
 */
 void __init ux500_init_irq(void)
 {
-	gic_arch_extn.flags = IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MASK_ON_SUSPEND;
+	gic_arch_extn.flags = IRQCHIP_SKIP_SET_WAKE;
 	irqchip_init();
 
 	/*

index 31a6fa40ba37..6defcea545d6 100644
@@ -182,7 +182,7 @@ static void __init zynq_map_io(void)
 
 static void __init zynq_irq_init(void)
 {
-	gic_arch_extn.flags = IRQCHIP_SKIP_SET_WAKE | IRQCHIP_MASK_ON_SUSPEND;
+	gic_arch_extn.flags = IRQCHIP_SKIP_SET_WAKE;
 	irqchip_init();
 }
 

index 7e11c9d6ae8c..0117e36a3bbd 100644
@@ -1032,6 +1032,7 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
 	}
 
 	gic_chip.flags |= gic_arch_extn.flags;
+	gic_chip.flags |= IRQCHIP_MASK_ON_SUSPEND;
 	gic_dist_init(gic);
 	gic_cpu_init(gic);
 	gic_pm_init(gic);

1.9.1

No. Lazy irq disable and the suspend logic are different beasts.

That's up to the platform to decide this. Just for the record: there is a world outside of ARM...

But that brings me to a different question:

Why are you not putting that customization into the device tree instead of trying to add this to some random arch/arm/mach-foo files?

Thanks,

tglx

OK, fair enough. Drop that random thought then. It's not in the patch content anyway.

OK. But GIC is ARM-specific, so we can still constrain this patch and related topics to the world of ARM.

I'm not adding customization to arch/arm/mach-foo files. I'm trying to remove it.

This property could be added to device tree, if there was really a valid use case for a GIC which leaves its interrupts unmasked for suspend. My question in this patch is essentially: does such a use case exist?

Brian

DT should genernally only contain data that's expected to vary between boards, or just possibly between SoCs. Anything that the kernel knows simply because it knows what HW model it's driving has no place in DT, since it just adds redundant work to parse the DT and end up with the same data.