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: -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
