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

Laurent Pinchart
2008-07-24T13:18:16Z

[-- 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 --]