On Mon, Jul 22, 2019 at 12:04:14PM +0200, Uwe Kleine-König wrote: > Hello Russell, > > On Mon, Jul 22, 2019 at 10:57:21AM +0100, Russell King - ARM Linux admin wrote: > > However, RTS is not guaranteed to stop the remote end sending characters > > as soon as it is deasserted - 16550 relies on software noticing that > > CTS has changed, and even then it may have a FIFO full of characters > > already queued to be sent that will still be sent. > > > > So, disabling RTS just before changing the baud doesn't give any > > guarantees that a character won't be in the process of being received > > while we're changing the baud rate, which means disabling it doesn't > > actually gain us anything. > > <sarcasm>With that reasoning we can drop RTS driving completely. Let's > just assert it unconditionally.</sarcam> Please, I'm being serious. > Right, deasserting RTS doesn't help against long receive FIFOs or > senders that react slowly (or not at all), but still it's better than > nothing, isn't it? Not really. In the normal use case of RTS, RTS doesn't get deasserted when there is no buffer space available, but when the available buffer space reaches a low-threshold. Buffer space remains to allow the sender to react to the change of RTS state. In the case you are promoting, which is to deassert RTS and then immediately start changing the port settings, you are not giving any chance for the sender to react to that state change. You could even be mid-way through receiving a character from the remote end - and at 75 baud, a single character lasts around 133ms. Even if you wait 133ms, that doesn't mean that the remote end has finished sending. If the remote end has a 16 byte FIFO, you'd need to wait about 2.2 seconds. At faster baud rates, of course the delay gets shorter. Just deasserting RTS just before changing the port settings gains very little protection. You need a character-period based delay as well. If we do start adding delays, it means that changing the baud rate for a port set to 75 baud starts taking ages to complete if CRTSCTS is enabled, irrespective of the settings change mode that was requested by userspace. However, adding delays is likely to screw up various userspace applications, such as those that do need to change baud rate at specific points in their protocol. -- 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
