Re: [PATCH v2] serial: sc16is7xx: fix data corruption due to unexpected xon/xoff

[sashiko-bot@kernel.org]

> The hardware supports automatically sending XON/OFF based on the
> FIFO status and that is already implemented by the driver.
> However that capability was not announced with the UPF_SOFT_FLOW bit.
> 
> When the port is opened with the default of XON enabled the driver
> configures that in the hardware.
> If userspace does not want XON/OFF (which is normally the case) it will
> use TCSETS to disactivate it. However the serial core optimises this
> to only notify the driver if someting imporant has changed, and for
> XON/XOFF thit is only if the  driver declares UPF_SOFT_FLOW.
> 
> So we end up with unwanted XON/XOFF in the data stream.
> 
> The problem only occurs if nothing else needed to be set by termios,
> ie if the user space requested values are the same as the default values,
> except for XON/XOFF.
> Since the default speed is 9600 this means that the problem only occurs
> when requesting 9600, otherwise the call to the driver will be made to
> change the speed, and that will also clear the XON/XOFF.
> As 9600 is quite rare these days that probably explains why this hasn't
> already been seen.
> 
> It also only occurs on the first port open after boot since the subsequent
> opens will use the "logical state" set by TCSETS but not communicated to
> the driver the first time.
> 
> Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001100534.1225894-1-martin.fuzzey@flowbird.group?part=1