----- Original Message ----- > From: "Aaron Sierra" <asierra@xxxxxxxxxxx> > To: "Andy Shevchenko" <andriy.shevchenko@xxxxxxxxxxxxxxx> > Cc: "Greg Kroah-Hartman" <gregkh@xxxxxxxxxxxxxxxxxxx>, "linux-serial" <linux-serial@xxxxxxxxxxxxxxx>, "Jan Kiszka" > <jan.kiszka@xxxxxxxxxxx>, "Sudip Mukherjee" <sudip.mukherjee@xxxxxxxxxxxxxxx> > Sent: Wednesday, July 18, 2018 4:36:50 PM > Subject: Re: [PATCH v1 1/3] serial: 8250_exar: Move the Exar bits from 8250_port > ----- Original Message ----- >> From: "Andy Shevchenko" <andriy.shevchenko@xxxxxxxxxxxxxxx> >> To: "Aaron Sierra" <asierra@xxxxxxxxxxx> >> Sent: Wednesday, July 18, 2018 12:15:06 PM > >> On Wed, 2018-07-18 at 11:22 -0500, Aaron Sierra wrote: >>> ----- Original Message ----- >>> > From: "Andy Shevchenko" <andriy.shevchenko@xxxxxxxxxxxxxxx> >>> > To: "Aaron Sierra" <asierra@xxxxxxxxxxx> >>> > Sent: Wednesday, July 18, 2018 9:38:46 AM >>> > On Tue, 2018-07-17 at 11:12 +0300, Andy Shevchenko wrote: >>> > >>> > Aaron, while addressing your comment I noticed that your patch >>> > (c7e1b4059075) actually might bring a regression in some cases. >>> >>> Andy, >>> You may be right about that. I'll take a look. Please see my other >>> comments below. >> >> Thanks for quick response. My answers below. >> >>> >>> > See below what I have as a patch in my WIP tree (https://bitbucket.o >>> > rg/a >>> > ndy-shev/linux/branch/topic/uart/rpm) >>> > >>> > I wouldn't go further with 8250_exar until I hear from you about >>> > this. >>> > Some clarifications would be nice to have. >>> > >>> > --- 8< --- 8< --- >>> > >>> > From 19e0b71fe8bd7b2562c05c993f0e60315f2a3205 Mon Sep 17 00:00:00 >>> > 2001 >>> > From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> >>> > Date: Tue, 17 Jul 2018 19:31:06 +0300 >>> > Subject: [PATCH] serial: 8250_exar: Revert "Relocate sleep wake-up >>> > handling" >>> > >>> > While benefits listed in the commit c7e1b4059075 sounds plausible, >>> > it >>> > seems it breaks expansion board support. >>> >>> Do you have any evidence that this is causing breakage in the wild or >>> is >>> this speculation for the time being? >> >> No evidence, just some time spent on data sheet and trying to understand >> how it might work all together. > > Andy, > Ok, that's good to know. Andy, I don't have any means to test this, so should I follow your lead with this patchset and ask for testers in a new patchset? I've included my proposed solution here for your initial feedback: ---- start patch ---- commit a21ae841664aae4c16452a216e26e3a3854fd14c Author: Aaron Sierra <asierra@xxxxxxxxxxx> Date: Wed Jul 18 17:56:37 2018 -0500 serial: 8250_exar: Read INT0 from slave device, too My sleep wake-up refactoring in c7e1b4059075 ("tty: serial: exar: Relocate sleep wake-up handling") did not account for devices with a slave device on the expansion port. This patch pokes the INT0 register in the slave device, if present, in order to ensure that MSI interrupts don't get permanently "stuck" because of a sleep wake-up interrupt as described in the original implementation: 2c0ac5b48a35 ("serial: exar: Fix stuck MSIs") Signed-off-by: Aaron Sierra <asierra@xxxxxxxxxxx> diff --git a/drivers/tty/serial/8250/8250_exar.c b/drivers/tty/serial/8250/8250_exar.c index 60b2b48..7c1880a 100644 --- a/drivers/tty/serial/8250/8250_exar.c +++ b/drivers/tty/serial/8250/8250_exar.c @@ -524,6 +524,10 @@ static irqreturn_t exar_misc_handler(int irq, void *data) /* Clear all PCI interrupts by reading INT0. No effect on IIR */ ioread8(priv->virt + UART_EXAR_INT0); + /* Clear INT0 for Expansion Interface slave ports, too */ + if (priv->board->num_ports > 8) + ioread8(priv->virt + (8 * 0x400) + UART_EXAR_INT0); + return IRQ_HANDLED; } ---- end patch ---- -Aaron S. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
