From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King Subject: Re: [PATCH/RFC] 8250: Auto RS485 direction control Date: Thu, 24 Jul 2008 13:52:11 +0100 Message-ID: <20080724125210.GD9327@flint.arm.linux.org.uk> References: <200807241347.33261.laurentp@cse-semaphore.com> <20080724125706.19844a96@lxorguk.ukuu.org.uk> <20080724122402.GC9327@flint.arm.linux.org.uk> <20080724132746.1a961584@lxorguk.ukuu.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from caramon.arm.linux.org.uk ([78.32.30.218]:38920 "EHLO caramon.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751136AbYGXMw3 (ORCPT ); Thu, 24 Jul 2008 08:52:29 -0400 Content-Disposition: inline In-Reply-To: <20080724132746.1a961584@lxorguk.ukuu.org.uk> Sender: linux-serial-owner@vger.kernel.org List-Id: linux-serial@vger.kernel.org To: Alan Cox Cc: Laurent Pinchart , linux-serial@vger.kernel.org On Thu, Jul 24, 2008 at 01:27:46PM +0100, Alan Cox wrote: > > On devices which don't support hardware RS485, what should be done is > > the termios bit remains clear, so that programs can tell if the port > > doesn't support it (as per POSIX.) > > Or the serial layer should do it in software. > > > I would also stress that this feature should be limited to enabling > > _hardware_ RS485 support, and not software emulation of that. The > > reason being is that with plain 16550 UARTs, the best you can do > > with interrupts is to know when the last character is transferred out > > of the transmit holding register into the transmit shift register - in > > other words, before the last character has finished transmission. > > So the 16550 sucks, that's not true of everyone elses uarts. It's true of all 8250 compatibles which don't have hardware RS485 support. I think that's all of them except 16850 and 16960. > > Basically, software RS485 is very yucky, and we've always resisted > > having that support in the kernel. > > Agreed entirely. Which takes us more and more to the setserial path even > if it means standardising some setserial bit to get everyone back in line. I don't have a problem with that, except one question: CRTSCTS. A while back, there were people asking for: 1. handshaking on DTR/DSR rather than RTS/CTS. 2. a different handshaking method for RTS/CTS (where you assert RTS to ask for permission to send when you actually have something to send.) Should CRTSCTS be a global "enable some kind of flow control" bit and setserial be used to configure the actual flow control method (conventional RTS/CTS, DTR/DSR, alternate RTS/CTS, RS485 on RTS, RS485 on DTR) ? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: