Subject: Re: [Patch] new serial flow control
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Chuck Ebbert <76306.1226@compuserve.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       Russell King <rmk@arm.linux.org.uk>, sebastien.hinderer@libertysurf.fr
In-Reply-To: <20041005172522.GA2264@bouh.is-a-geek.org>
References: <200410051249_MC3-1-8B8B-5504@compuserve.com>
	 <20041005172522.GA2264@bouh.is-a-geek.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1097176130.31557.117.camel@localhost.localdomain>
Mime-Version: 1.0
Date: Thu, 07 Oct 2004 20:08:56 +0100
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 869
Lines: 22

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.

Thoughts ?

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/