Sergey, I don't get your emails because you bypass Google's servers, meaning that your emails purportedly from gmail.com come through unsigned with google's DKIM signature - just like _so_ much spam. On Sat, Jun 01, 2019 at 06:12:56PM +0200, Uwe Kleine-König wrote: > Hello, > > On Fri, May 31, 2019 at 09:38:37PM +0300, Sergey Organov wrote: > > Russell King <rmk@xxxxxxxxxxxxxxx> writes: > > > 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? It does not. If the serial port raises a receive interrupt, then the interrupt gets serviced, which means characters are read from the FIFO and are attempted to be inserted into the TTY receive buffer. If the TTY receive buffer is full, they will be discarded. This is entirely reasonable: the kernel monitors the level of the TTY receive buffer, and takes measures to prevent it becoming that full by using flow control - which, for hardware flow control, means that the kernel issues set_mctrl() to deassert RTS. Think about it - if we have a port that does not have hardware assisted RTS, then how does RTS become inactive - if the kernel stops reading characters from the FIFO, the hardware FIFO will overflow, and RTS will remain true. If we want the kernel to stop reading the FIFO, we would have to add additional complexity to a lot of serial drivers, and a capability which tells the kernel that they support this behaviour - why do we want individual drivers to have to implement this? History has shown that the more low-level drivers have to implement, the more bugs we end up with, so keeping the complexity to a minimum is best - requiring serial drivers deassert RTS when there is hardware assisted flow control and the kernel wishes to do so is _less_ complex than having some mechanism to stop reading the FIFO. > Not all hardware has a FIFO and the necessary mechanisms to > auto-deassert RTS when it fills. So there must be support in software to > deassert RTS, too. And even in the presence of a "smart" FIFO, the > software then usually knows earlier about having to stop the other side > and this might be the necessary margin that makes them stop before the > local buffer is over full. Yes, some sending ports have a deep FIFO and may not support hardware assisted CTS - which means they could send maybe up to 128 additional bytes after RTS is deasserted, though 16 is more usual. At least that is what I remember of some of the enhanced 8250-based chips. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
