| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20080214115550.7aa7c98b@core> Date: Thu, 14 Feb 2008 11:55:50 +0000 From: Alan Cox <alan@...rguk.ukuu.org.uk> To: Greg KH <greg@...ah.com> Cc: David Newall <davidn@...idnewall.com>, linux-usb@...r.kernel.org, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: Handshaking on USB serial devices On Wed, 13 Feb 2008 21:02:11 -0800 Greg KH <greg@...ah.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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists