Phil Wilshire wrote:
> minicom -o
> will stop the AT commands being issued.
Thanks for the tip, Phil. But I am more concerned about the actual
bug.
> I would fix the linux driver to stop the race.
Since there's no hope that NXP will fix the problem, this is the only
way to go.
The primary questions are:
- Is this problem limited to NXP or are other chips affected and
nobody noticed? In other words: should this fix be specific to NXP
or more general?
- How to fix it properly? Currently, I tend to call receive-chars()
not only when UART_LSR_DR is set, but also when UART_IIR_RDI is
set. After all, the receive interrupt signals that data is
available. Please check attached patch. It works fine with the
lpc2214 chip. And it should (IMHO) not break anything because an
asserted RDI actually signals that data is available.
- Finally the most important question: should the patch be integrated
in the official sources? I think it should be safe to integrate it.
diff -urw linux-2.4.32.orig/drivers/char/serial.c
linux-2.4.32/drivers/char/serial.c
--- linux-2.4.32.orig/drivers/char/serial.c 2007-10-17
14:43:41.000000000 +0200
+++ linux-2.4.32/drivers/char/serial.c 2007-10-17 15:19:39.000000000
+0200
@@ -1118,7 +1118,7 @@
#ifdef SERIAL_DEBUG_INTR
printk("status = %x...", status);
#endif
- if (status & UART_LSR_DR)
+ if ((status & UART_LSR_DR) || (iir & UART_IIR_RDI))
receive_chars(info, &status, regs);
check_modem_status(info);
#ifdef CONFIG_MELAN
@@ -1131,7 +1131,7 @@
transmit_chars(info, 0);
#endif
if (pass_counter++ > RS_ISR_PASS_LIMIT) {
-#if SERIAL_DEBUG_INTR
+#ifdef SERIAL_DEBUG_INTR
printk("rs_single loop break.\n");
#endif
break;
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
