All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Russell King <rmk+lkml@arm.linux.org.uk>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-serial@vger.kernel.org
Subject: Re: Serial 8250: clear the lsr_break_flag at open
Date: Tue, 01 May 2007 08:23:14 -0500	[thread overview]
Message-ID: <46373F42.4080305@acm.org> (raw)
In-Reply-To: <20070501092933.GB18233@flint.arm.linux.org.uk>

Russell King wrote:
> On Mon, Apr 30, 2007 at 05:08:59PM -0500, Corey Minyard wrote:
>   
>> 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.  I've done some experiments
and that seems to be the case, though.

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?

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.

If this is really a problem, I'd be glad to generate another patch.

-corey

  reply	other threads:[~2007-05-01 13:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-30 22:08 Serial 8250: clear the lsr_break_flag at open Corey Minyard
2007-05-01  9:29 ` Russell King
2007-05-01 13:23   ` Corey Minyard [this message]
2007-05-03 12:08     ` Russell King
2007-05-04  3:43       ` Corey Minyard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46373F42.4080305@acm.org \
    --to=minyard@acm.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.