Re: [PATCH/RFC] 8250: Auto RS485 direction control

[Russell King <rmk@arm.linux.org.uk>]

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: