Uwe, this is more ment for Sergey, I don't seem to have his emails obviously to hand... On Fri, May 31, 2019 at 08:28:09AM +0200, Uwe Kleine-König wrote: > Hello, > > On Fri, May 31, 2019 at 08:33:15AM +0300, Sergey Organov wrote: > > This is still wrong, as it turns off RTS/CTS handshake in hardware on > > TIOCM_RTS=0. Once again, set_mctrl() should not touch UCR2_CTSC, -- it's > > as simple as that. That is incorrect. The point of hardware flow control is to stop the remote end when the buffers at the receiver fill up, and by "buffers" I mean _either_ the FIFO or the kernel's buffers. With serial ports that do not have hardware RTS support, the kernel can only notify the remote end that the kernel buffers are full, and it does this by calling set_mctrl() to deassert RTS. Some serial ports have additional hardware that allows them to automatically deassert the RTS signal when the receive FIFO is in danger of overflowing - this is entirely supplementary to the above mechanism, so the conditions for deasserting the RTS signal when CRTSCTS is set become: If the kernel buffers fill up, and the kernel calls set_mctrl() with RTS false, _or_ the hardware decides that the FIFO is close to overflowing and itself decides to deassert RTS, then RTS should be deasserted. Ergo, if the driver's set_mctrl() is called with RTS=0, then RTS must be force-deasserted whether or not hardware assisted flow control is enabled. If this is not done, data loss will occur: characters will be received from the FIFO, and the attempt to place them into the kernel buffer will fail, resulting in the characters being discarded. This would not be an effective hardware flow control implementation. -- Russell King ARM architecture Linux Kernel maintainer, ex-serial maintainer, author of the serial-core and the basis of the serial structure in drivers/tty/serial.
