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

[Laurent Pinchart <laurentp@cse-semaphore.com>]

[-- Attachment #1: Type: text/plain, Size: 2440 bytes --]

On Thursday 24 July 2008, Russell King wrote:
> 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.

I agree as well. Implementing various type of flow control emulation would require some kind of real-time support and lots of hacks to work around hardware issues. The serial core is complex enough as it is today.

> > 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) ?

That sounds nice, although the CRTSCTS will not mean much anymore. I suppose the new setserial option will have a 'RTS/CTS handshake' default value, so that current drivers will exhibit the correct behaviour.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]