On Tue, May 01, 2007 at 08:23:14AM -0500, Corey Minyard wrote:

Russell King wrote:

quoted

On Mon, Apr 30, 2007 at 05:08:59PM -0500, Corey Minyard wrote:
 

quoted

I'm having a hard time understanding why the lsr_break_flag
is necessary.
   

Merely reading the LSR clears status bits.  We read the LSR repeatedly
so that we can monitor the transmit FIFO when outputting serial console
messages.

This means that if you have a busy serial console, and you want to send
it a sysrq request, there's a chance that the break flag in the LSR will
be cleared by the transmit FIFO status polling code thereby being lost.

So, we need to remember that status, and we do this via the lsr_break_flag.
 

I should have said a little more.  I couldn't find anywhere in any docs
for this that said it was a destructive read.

The TI 16550A data sheet says:

* Bit 1: This bit is the overrun error (OE) indicator. ... The OE indicator
  is cleared every time the CPU reads the contents of the LSR.

* Bit 2.: This bit is the parity error (PE) indicator. ... The PE bit is
  cleared every time the CPU reads the contents of the LSR.

* Bit 3: This bit is the framing error (FE) indicator. ... The FE bit is
  cleared every time the CPU reads the contents of the LSR.

* Bit 4: This bit is the break interrupt (BI) indicator. ... The BI bit is
  cleared every time the CPU reads the contents of the LSR.

So two things:

There are other bits in this register that also appear to be destroyed on
read: framing, parity, and overrun.  Should those be saved, too?

Yes.

There are several places where the LSR is read and nothing is done
for this, in serial8250_start_tx, serial8250_backup_timeout, and
serial8250_tx_empty.  It seems like these would need to be handled,
too.

The backup code is something I never properly reviewed, so no comments
there.  The tx_empty code I assumed would be a relatively rare event,
except when closing the port (at which point you don't particularly care
about errors anyway, not even the break flag since chances are you'll
miss the following character.)

Given that people might want to poll it for various reasons, I guess
saving the status away should be done.  However, there's a slight issue
with working out which character the error is associated with.  Careful
locking may be the answer to that though.

As for start_tx, yes, though slightly harder to check.  Maybe the code
should be modified to reduce the number of potential LSR reads by reading
the IIR first, and only if that shows no interrupt pending should the LSR
be read (and the error flags remembered.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of: