Messages in this thread | | | Date | Mon, 26 Jun 2006 22:07:47 +0200 | From | Ingo van Lil <> | Subject | Serial: UART_BUG_TXEN race conditions |
| |
Hello everybody,
I'm currently working with Linux on a custom ASIC system with two crappy UART ports that show a behaviour quite similar to the problem that the UART_BUG_TXEN workaround is supposed to deal with. The interesting lines are in serial8250_start_tx (drivers/serial/8250.c:1127)
if (up->bugs & UART_BUG_TXEN) { unsigned char lsr, iir; lsr = serial_in(up, UART_LSR); iir = serial_in(up, UART_IIR); if (lsr & UART_LSR_TEMT && iir & UART_IIR_NO_INT) transmit_chars(up); }
Correct me if I'm mistaken, but I see two possible race conditions with that piece of code:
1. What if the IIR actually equals UART_IIR_THRI at that point? The read access will clear the interrupt condition and the workaround will effect the actual opposite of its intention: Neither serial8250_start_tx() nor the interrupt handler will start transmitting characters for the ring buffer.
2. What if an interrupt is triggered shortly after reading the IIR? Both serial8250_start_tx() and the interrupt handler will start a transmission simultaneously.
Problem #1 should be quite easy to deal with: If the IIR read comes out as UART_IIR_THRI then the interrupt handler won't initiate a transmission, so we should. I'm not entirely sure how to deal with #2, though. Maybe it's enough to clear the THRE bit while transmitting characters, maybe some kind of locking is required.
Cheers, Ingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |