public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Andrew Morton <akpm@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Correctly flush 8250 buffers, notify ldisc of line status changes.
Date: Tue, 09 Nov 2004 13:17:22 +0000	[thread overview]
Message-ID: <1100006241.15742.6.camel@localhost.localdomain> (raw)
In-Reply-To: <20041109132810.A15570@flint.arm.linux.org.uk>

>
> The status change and character receive are asynchronous with respect
> to each other anyway.  Consider the case where the serial port says
> "we have characters waiting" - we receive a FIFO full of characters.
> It then says that the modem status has changed.

Only to a small degree, and the fifo is configurable in software. RS485
multi
drop users do generally run with FIFO and the message boundaries mean
that the
event accuracy is good enough.

What the callback does is provide a notification *before* the data
arrives, and easily 2mS out which calls a line discipline function that
cannot sleep and cannot viably interact with the data stream.

In addition you've not defined the semantics of that function for
calling back into the tty driver. You tell me "carrier dropped", yet in
that routine you don't define what occurs if I want to respond by
lowering my carrier too.
Right now it'll deadlock if I do anything in that function of any
relevance.

So its broken, totally and utterly. Its the kind of undefined,
unserialized crap that I'm trying to get _OUT_ of the serial layer.

Now when you add it to the flip buffer as another event like errors the
line discipline knows the approximate time it occurred, has defined
semantics for ordering and queuing and can respond by flipping its modem
signals. You can
actually *use* it to implement things like half-duplex and multidrop.

Andrew - please reject the patch.

Alan


  reply	other threads:[~2004-11-09 14:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-05 13:06 [PATCH] Correctly flush 8250 buffers, notify ldisc of line status changes David Woodhouse
2004-11-05 13:08 ` David Woodhouse
2004-11-09  9:22 ` Andrew Morton
2004-11-09 11:07   ` David Woodhouse
2004-11-09 11:15     ` Alan Cox
2004-11-09 13:28       ` Russell King
2004-11-09 13:17         ` Alan Cox [this message]
2004-11-09 14:39           ` David Woodhouse
2004-11-09 13:49             ` Alan Cox
2004-11-09 14:47           ` Russell King
2004-11-09 14:47             ` Alan Cox
2004-11-13 18:10               ` Russell King
2004-11-13 20:52                 ` Alan Cox
2004-11-13 22:40                   ` Nicolas Pitre
2004-11-09 14:39       ` David Woodhouse

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=1100006241.15742.6.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=akpm@osdl.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox