On Mon, Jun 03, 2019 at 03:08:06PM +0300, Sergey Organov wrote: > Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx> writes: > > [...] > > > 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? > > How does it work when no handshake is configured? Drivers continue to > read FIFOs/TxDs and drop data when software buffers are full, spending > CPU cycles on nothing? I assume what you mean by "no handshake" is "no flow control", then yes, the CPU continues to read the FIFO and drops the received characters on the floor. When no flow control is configured, it means there is no way to signal to the remote end that there is congestion at the receiving end, and if there is no buffer space available, where would you expect the received characters to be stored? If the CPU were to stop reading the FIFO, the result would be that the FIFO fills, and then any further characters received get discarded by the hardware (instead of the CPU) and the hardware marks an overrun error. -- 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
