From owner-freebsd-hardware Tue Jan 30 7:21: 9 2001 Delivered-To: freebsd-hardware@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 13AE237B4EC; Tue, 30 Jan 2001 07:20:51 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id CAA22386; Wed, 31 Jan 2001 02:20:42 +1100 Date: Wed, 31 Jan 2001 02:20:29 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Juha.Nurmela@quicknet.inet.fi Cc: freebsd-hardware@FreeBSD.ORG, dg@FreeBSD.ORG Subject: Re: sio RTS stays asserted after close In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 30 Jan 2001 Juha.Nurmela@quicknet.inet.fi wrote: > Noticed that serial port RTS does not drop inactive when > a sio-device is closed. DTR does drop. I suppose the hupcl 'modem > disconnect' operation does not necessarily require RTS to drop, > still, isn't it a bit silly to leave RTS high when DTR goes low > in this case ? This omission might be intentional, fine then. It is intentional: RCS file: /home/ncvs/src/sys/isa/sio.c,v Working file: sio.c head: 1.321 ... ---------------------------- revision 1.11 date: 1993/10/14 09:13:54; author: davidg; state: Exp; lines: +7 -7 Disassociate DTR and RTS. They were coupled together and shouldn't have been. This was necessary to work around problems with some equipment that don't respond favorably to having these both dropped simultaneously. ---------------------------- I have never liked it, and welcome this excuse to not do it :-). Before this change, DTR and RTS were also coupled in TIOCSDTR and TIOCDTR. That was clearly wrong, at least if RTS is not being used for flow control, since it breaks using the modem status lines independently for special (non-modem) applications. > Also noticed there were issues with DTR getting overwritten whenever line > is reconfigured (comparam()). This will not bite if the termios are > set initially by a program and then only reads, writes and TIOCMBIC/BIS > are used, by this single program only ? (meaning, no spontaneous > comparams happen ? (console is elsewhere)) Yes, comparams only happen for opens and termios ioctls (TIOCSETA*). Setting DTR for most termios ioctls unfortunately seems to be required in practice, since clearing DTR is required when the output speed is 0 and there is no official termios way to raise DTR. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message