From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
Chuck Ebbert <76306.1226@compuserve.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
sebastien.hinderer@libertysurf.fr
Subject: Re: [Patch] new serial flow control
Date: Thu, 7 Oct 2004 21:27:22 +0100 [thread overview]
Message-ID: <20041007212722.G8579@flint.arm.linux.org.uk> (raw)
In-Reply-To: <1097176130.31557.117.camel@localhost.localdomain>; from alan@lxorguk.ukuu.org.uk on Thu, Oct 07, 2004 at 08:08:56PM +0100
On Thu, Oct 07, 2004 at 08:08:56PM +0100, Alan Cox wrote:
> On Maw, 2004-10-05 at 18:25, Samuel Thibault wrote:
> > No: data actually pass _after_ CTS and RTS are lowered back: the flow control
> > only indicate the beginning of one frame.
>
> Ok I've pondered this somewhat. I don't think the hack proposed is the
> right answer for this. I believe you should implement a simple line
> discipline for this device so that it stays out of the general code.
>
> Right now that poses a challenge but if drivers were to implement
> ldisc->modem_change() or a similar callback for such events an ldisc
> could then handle many of the grungy suprises and handle them once and
> in one place.
To me at least that sounds like a good solution. I can't help but
wonder whether moving some of the usual modem line status change
processing should also be moved into the higher levels. This will
probably make more sense if the "block till ready" code also moves,
which I think Ted was considering at one point.
However, that's probably something to think about later.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
next prev parent reply other threads:[~2004-10-07 20:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-05 16:46 [Patch] new serial flow control Chuck Ebbert
2004-10-05 17:25 ` Samuel Thibault
2004-10-07 19:08 ` Alan Cox
2004-10-07 20:27 ` Russell King [this message]
2004-10-07 22:08 ` Samuel Thibault
2004-10-07 23:10 ` Russell King
2004-10-07 21:43 ` Samuel Thibault
2004-10-07 22:55 ` Samuel Thibault
2004-10-08 18:59 ` Samuel Thibault
-- strict thread matches above, loose matches on Subject: below --
2004-10-07 11:08 Nick Craig-Wood
2004-10-04 22:54 Samuel Thibault
2004-10-04 22:55 ` Samuel Thibault
2004-10-05 22:51 ` Alan Cox
2004-10-06 7:11 ` Sébastien Hinderer
2004-10-06 7:38 ` Samuel Thibault
2004-10-06 13:29 ` Alan Cox
2004-10-07 1:30 ` Stuart MacDonald
2004-10-07 1:47 ` Paul Fulghum
2004-10-07 7:26 ` Sébastien Hinderer
2004-10-07 13:00 ` Alan Cox
2004-10-07 14:28 ` Samuel Thibault
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=20041007212722.G8579@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=76306.1226@compuserve.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=samuel.thibault@ens-lyon.org \
--cc=sebastien.hinderer@libertysurf.fr \
/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