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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
