linux-kernel - [PATCH resend] iop13xx: workaround errata that causes uart interrupts to be missed

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>] [day] [month] [year] [list]

Message-ID: <20091112035728.18068.39520.stgit@dwillia2-linux.ch.intel.com>
Date:	Wed, 11 Nov 2009 20:58:36 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	alan@...rguk.ukuu.org.uk
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH resend] iop13xx: workaround errata that causes uart interrupts
	to be missed

Reading the uart iir register sometimes results in the interrupt being
cleared without being reported.  Use the the system interrupt pending
register as a fallback.

This converts locations in the code that only care about the interrupt
pending bit to use the iir_int_status() macro.

Signed-off-by: Dan Williams <dan.j.williams@...el.com>
---

Hi Alan,

Looking for an acked-by or advice on how to get this hack upstream.  I
have been carrying it for a while out of tree [1], but that is getting
tiresome.  Russell pointed me at you as the gatekeeper of 8250.c, but
feel free to redirect me if someone else is looking after this file
these days.

Thanks,
Dan

[1]: http://git.kernel.org/?p=linux/kernel/git/djbw/xscaleiop.git;a=commitdiff;h=a7d124f5 

 drivers/serial/8250.c |   38 +++++++++++++++++++++++++++++++++++---
 1 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index b1ae774..2c440d1 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -547,6 +547,38 @@ serial_out_sync(struct uart_8250_port *up, int offset, int value)
 	(up->port.serial_in(&(up)->port, (offset)))
 #define serial_out(up, offset, value)	\
 	(up->port.serial_out(&(up)->port, (offset), (value)))
+
+#ifndef CONFIG_ARCH_IOP13XX
+#define iir_int_status(up) serial_in((up), UART_IIR)
+#else
+/* A silicon issue on IOP13XX causes IIR reads to return UART_IIR_NO_INT
+ * even if an interrupt is pending. Use the system interrupt pending
+ * register to check for servicing as a workaround.
+ */
+#include <mach/irqs.h>
+static unsigned int iir_int_status(struct uart_8250_port *up)
+{
+	unsigned long membase = (unsigned long) up->port.membase;
+	unsigned long ipnd, iir;
+
+	ipnd = read_intpnd_1();
+	iir = UART_IIR_NO_INT;
+
+	if (membase == IOP13XX_UART0_VIRT) {
+		if (ipnd & (1 << (IRQ_IOP13XX_UART0 - 32)))
+			iir &= ~UART_IIR_NO_INT;
+	} else if (membase == IOP13XX_UART1_VIRT) {
+		if (ipnd & (1 << (IRQ_IOP13XX_UART1 - 32)))
+			iir &= ~UART_IIR_NO_INT;
+	} else
+		BUG();
+
+	/* clear the interrupt via the LSR */
+	mem_serial_in(&up->port, UART_LSR);
+	return iir;
+}
+#endif
+
 /*
  * We used to support using pause I/O for certain machines.  We
  * haven't supported this for a while, but just in case it's badly
@@ -1572,7 +1604,7 @@ static irqreturn_t serial8250_interrupt(int irq, void *dev_id)
 
 		up = list_entry(l, struct uart_8250_port, list);
 
-		iir = serial_in(up, UART_IIR);
+		iir = iir_int_status(up);
 		if (!(iir & UART_IIR_NO_INT)) {
 			serial8250_handle_port(up);
 
@@ -1732,7 +1764,7 @@ static void serial8250_timeout(unsigned long data)
 	struct uart_8250_port *up = (struct uart_8250_port *)data;
 	unsigned int iir;
 
-	iir = serial_in(up, UART_IIR);
+	iir = iir_int_status(up);
 	if (!(iir & UART_IIR_NO_INT))
 		serial8250_handle_port(up);
 	mod_timer(&up->timer, jiffies + poll_timeout(up->port.timeout));
@@ -1753,7 +1785,7 @@ static void serial8250_backup_timeout(unsigned long data)
 		serial_out(up, UART_IER, 0);
 	}
 
-	iir = serial_in(up, UART_IIR);
+	iir = iir_int_status(up);
 
 	/*
 	 * This should be a safe test for anyone who doesn't trust the

--
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/