From mboxrd@z Thu Jan 1 00:00:00 1970 From: Krzysztof Halasa Subject: Re: should RTS init in serial core be tied to CRTSCTS Date: Fri, 09 Mar 2007 21:39:14 +0100 Message-ID: References: <000201c761b1$a281cdf0$2e01a8c0@acksys.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from khc.piap.pl ([195.187.100.11]:37145 "EHLO khc.piap.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752444AbXCIUjR (ORCPT ); Fri, 9 Mar 2007 15:39:17 -0500 In-Reply-To: <000201c761b1$a281cdf0$2e01a8c0@acksys.local> (Tosoni's message of "Thu, 8 Mar 2007 19:43:15 +0100") Sender: linux-serial-owner@vger.kernel.org List-Id: linux-serial@vger.kernel.org To: Tosoni Cc: 'Carl-Daniel Hailfinger' , 'Robin Getz' , 'Oleksiy Kebkal' , 'Mike Frysinger' , 'Linux Kernel Mailing List' , linux-serial@vger.kernel.org "Tosoni" writes: >> OTOH I wonder what does the device in question require WRT the >> serial port and WRT RTS line in particular. >> I know there are some half-duplex converters which drive RTS only >> while sending and which require CTS to send. > > As far as I know in the old times this was the *standard* way to use a modem > (per CCITT V24), and even nowadays many modems can handle this method for > transmit, to stay compatible with the standard. I think it wasn't standard for real modems as they were full-duplex (even these 1200/75 or what was that) but it was for other devices such as current loops (which were frequently half-duplex). I've seen such devices quite recently, perhaps ~ 10 years ago. OTOH I think even "current" PC BIOSes use such signaling. > Think of radio modems. Some are inherently half duplex. Sure. But /dev/ttyS* ports are full-duplex, with CRTSCTS or without, so they don't use such handshaking. >> They are perhaps a bit broken > No, no, they apply an old standard. Probably they are old as well. I was thinking of a particular piece of hardware and it was definitely broken a bit. "Selective compliance", maybe. > It's a pity that Linux (or Unixes) never handled RTS this way. > I feel that the /proc or sysfs solutions are the best to alter this well > established default in this driver. It would not break existing installed > hardware. /proc is probably no-no. For such signaling, it would perhaps be better to invent another flag, similar to CRTSCTS. The driver would, of course, need some real code for that. -- Krzysztof Halasa