Ralf Baechle wrote:
> On Thu, Oct 25, 2007 at 03:58:54PM +0200, Jan Nikitenko wrote:
>> UART0 on Alchemy mips platforms (au1xxx) does not use real uart's hw
>> irq, causing 'ttyS0: 1 input overrun(s)' kernel message with data loss,
>> when more characters than uart's fifo size were to be received by the uart.
>> This problem can be experienced for example when uart0 is used as a
>> serial console on au1550 and more than 16 characters are pasted from
>> clipboard to the console.
>> The is_real_interrupt(irq) macro is defined in drivers/serial/8250.c as
>> a check, if the irq number is other than zero.
>> Because UART0 on au1xxx platforms uses irq number 0, the
>> is_real_interrupt() check fails and serial8250_backup_timeout() is used
>> instead of uart's hw irq.
>> The patch redefines the is_real_interrupt(irq) macro, as suggested in
>> the comment above the macro definition in 8250.c, in the
>> asm-mips/serial.h to be always true for CONFIG_SERIAL_8250_AU1X00.
>> This allows the irq number 0 to be used as hw irq for the alchemy uart0
>> and fixes the overrun problem.
>> Signed-off-by: Jan Nikitenko <email@example.com>
> Fairly unelegent imho but anyway, for 2.6.24 I've added support for
> tickless to MIPS which in turn required a bit of a cleanup on the Alchemy
> code so I renumbered the Alchemy interrupt numbers, so what used to be
> IRQ 0 is now IRQ 8 which means your patch is no longer needed for master.
That's good to know.
> That said, irq 0 is imho totally valid (take the good old PIT timer
> interrupt of the PC as the classic example) and treating it as an invalid
> interrupt number is broken.
> It's however equally pretty crude hack to undefine a symbol in a file other
> than the one defining it ...
I did exactly as the comment in 8250.c suggested (that arch include
could redefine that macro) - I did not like it either...