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:
signature.asc
Description: This is a digitally signed message part.
