Russell King <rmk@xxxxxxxxxxxxxxx> writes: > 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. I thought it should work automagically when there is proper hardware RTS/CTS support, and I'm still not convinced it doesn't. > 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. I admittedly didn't expect upper level to call set_mctrl() to deassert RTS manually when driver has claimed hardware flow control, but even if it does, it seems like it could be safely ignored, see below. > 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. Why? Doesn't kernel stop its receiving machinery anyway when software receive buffers get filled? If it does, that seems logical, then it will rather stop reading from FIFO, and once FIFO fills above threshold (if at all), hardware will de-assert RTS by itself, no complications required. OTOH, if kernel doesn't stop receiving, and RTS/CTS handshake is off or is not obeyed by sender, kernel will continue to read from FIFO (and discard data) even when software buffers are full, potentially indefinitely. Somehow I doubt it's indeed the case. What do I miss? -- Sergey
