lkml.org 
[lkml]   [2006]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectSerial: 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/

\
 
 \ /
  Last update: 2006-06-26 22:10    [W:1.018 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site