> @@ -1553,7 +1554,15 @@ static void serial8250_handle_port(struct
> uart_8250_port *up)
> spin_lock_irqsave(&up->port.lock, flags);
>
> - status = serial_inp(up, UART_LSR);
> + /* Workaround for IRQ storm errata on break with Freescale
> 16550 */
> + if (UART_BUG_FSLBK & up->port.bugs && up->lsr_last &
> UART_LSR_BI) {
> + up->lsr_last &= ~UART_LSR_BI;
> + serial_inp(up, UART_RX);
> + spin_unlock_irqrestore(&up->port.lock, flags);
> + return;
> + }
> +
> + status = up->lsr_last = serial_inp(up, UART_LSR);
We've now had a recent pile of IRQ function changes adding more quirk
bits and special casing. This doesn't scale. We either need to make
handle_port a method the specific drivers can override or you could
hide the mess in your serial_inp implementation and not touch any core
code.
I really don't mind which but I suspect dealing with it in your
serial_inp handler so that when you read UART_LSR you do the fixup
might be simplest providing you can just do that.
Sorting out a ->handle_port override is probably ultimately the right
thing to do and then we can push some of the other funnies out further.
At this point it's becoming increasingly clear that 8250 UART cloners
are both very bad at cloning the things accurately, and very busy adding
extra useful features so we need to start to treat 8250.c as a library
you can wrap.
Alan
--
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
