Date: Thu, 14 Feb 2008 11:55:50 +0000
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Greg KH <greg@kroah.com>
Cc: David Newall <davidn@davidnewall.com>, linux-usb@vger.kernel.org,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Handshaking on USB serial devices
Message-ID: <20080214115550.7aa7c98b@core>
In-Reply-To: <20080214050211.GB1432@kroah.com>
References: <47B30291.2040905@davidnewall.com>
	<20080214050211.GB1432@kroah.com>
Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street,
 Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a
 Lloegr o'r rhif cofrestru 3798903
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1181
Lines: 27

On Wed, 13 Feb 2008 21:02:11 -0800
Greg KH <greg@kroah.com> wrote:

> On Thu, Feb 14, 2008 at 01:15:37AM +1030, David Newall wrote:
> > Consider a USB-attached serial port that is set to do RTS/CTS (or
> > DSR/DTR) handshaking: What stops the kernel sending more data to it when
> > the remote end lowers CTS (or DTR)?
> 
> The tty layer should look at the proper flags and not send data on to
> the driver in this kind of instance.

For outgoing data the tty ldisc will check the available room indicators
the driver provides and stop when they fill. We don't want to be directly
involved in flow control if possible as most decent hardware does RTS/CTS
handshaking in hardware (except in the PC world).

If your hardware is dumb (ie you do RTS/CTS in software) then you need to
track the CTS state and termios bits (in your set_termios method) and
transmit according to flow control rules, letting the buffer fill up
otherwise.

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/