linux-kernel - [PATCH] irqchip: omap-intc: fix spurious irq handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 19 Oct 2015 15:16:31 +0530
From:	Sekhar Nori <nsekhar@...com>
To:	Thomas Gleixner <tglx@...utronix.de>,
	Tony Lindgren <tony@...mide.com>,
	Jason Cooper <jason@...edaemon.net>,
	Marc Zyngier <marc.zyngier@....com>
CC:	John Ogness <john.ogness@...utronix.de>,
	Felipe Balbi <balbi@...com>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: [PATCH] irqchip: omap-intc: fix spurious irq handling

Under some conditions, irq sorting procedure used by INTC can go wrong
resulting in a spurious irq getting reported.

This condition is flagged by INTC by setting "Spurious IRQ Flag" in SIR
register to 0x1ffffff. Section 6.2.5 of AM335x TRM revised Jun 2014
describes this.

Using IRQ number 0 for checking this condition is wrong. 0 is a valid
INTC IRQ. For example, on AM335x, it is the emulation interrupt.

Fix handing of spurious interrupt condition in omap-intc driver by
correct detection of spurious interrupt condition.

Since spurious IRQ condition can happen under genuine conditions (see
the section of AM335x TRM for details) and is recoverable, we do not
need a warning splat for users to report. It can however result in
reduced performance so we add a ratelimited debug print to aid
developers.

Signed-off-by: Sekhar Nori <nsekhar@...com>
---
 drivers/irqchip/irq-omap-intc.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 8587d0f8d8c0..739725515fab 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -22,6 +22,8 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/ratelimit.h>
+#include <linux/printk.h>
 
 /* Define these here for now until we drop all board-files */
 #define OMAP24XX_IC_BASE	0x480fe000
@@ -47,6 +49,7 @@
 #define INTC_ILR0		0x0100
 
 #define ACTIVEIRQ_MASK		0x7f	/* omap2/3 active interrupt bits */
+#define SPURIOUSIRQ_MASK	(0x1ffffff << 7)
 #define INTCPS_NR_ILR_REGS	128
 #define INTCPS_NR_MIR_REGS	4
 
@@ -333,8 +336,23 @@ omap_intc_handle_irq(struct pt_regs *regs)
 	u32 irqnr;
 
 	irqnr = intc_readl(INTC_SIR);
+
+	/*
+	 * A spurious IRQ can result if interrupt that triggered the
+	 * sorting is no longer active during the sorting (10 INTC
+	 * functional clock cycles after interrupt assertion). Or a
+	 * change in interrupt mask affected the result during sorting
+	 * time. There is no special handling required except ignoring
+	 * the SIR register value just read and retrying.
+	 * See section 6.2.5 of AM335x TRM Literature Number: SPRUH73K
+	 */
+	if ((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK) {
+		pr_debug_ratelimited("%s: spurious irq!\n", __func__);
+		omap_ack_irq(NULL);
+		return;
+	}
+
 	irqnr &= ACTIVEIRQ_MASK;
-	WARN_ONCE(!irqnr, "Spurious IRQ ?\n");
 	handle_domain_irq(domain, irqnr, regs);
 }
 
-- 
2.4.4.408.g16da57c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/