[PATCH 00/11] Minimum set of omap serial patches to fix merge window breakage

[Russell King - ARM Linux]

On Tue, Oct 16, 2012 at 11:14:58AM +0100, Russell King - ARM Linux wrote:
> During the merge window, a series of patches from various people went in,
> allegedly fixing various problems with the OMAP serial driver.
> 
> Unfortunately, there was not a full understanding of the issues I brought
> up here back in April, and so the "fixes", while being individually
> correct, result in a worse situation with the driver than before.
> 
> Specifically, this patch:
> 
> commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6
> Author: Vikram Pandita <vikram.pandita at ti.com>
> Date:   Thu Sep 6 15:45:37 2012 +0300
> 
>     serial: omap: fix software flow control
> 
>     Software flow control register bits were not defined correctly.
> 
>     Also clarify the IXON and IXOFF logic to reflect what userspace wants.
> 
> does what it says on the tin - it fixes the register definitions so that
> we do end up enabling the right two software flow control bits.
> 
> The down side is that there are other bugs in this area which have been
> exposed.  For example:
> 
> 1. the XON/XOFF registers aren't written to; their address is, but we will
>    not be writing to the right registers because their access rules are not
>    respected by the driver.  These are by default zero.
> 
>    This means that with hardware assisted software flow control enabled,
>    the port will now transmit an 0x00 byte for XON and XOFF events.
> 
> 2. the driver set_termios function is not called for changes in software
>    flow control settings if not accompanied by some other change.
> 
> 3. the there isn't actually a way for the hardware assisted flow control
>    to be used other than by increasing interrupt latency to cause the
>    receiver hardware FIFO to fill.  This will cause 0x00 bytes to be
>    transmitted.
> 
> There are two options to resolve this.  The first one is to revert this
> patch to bring the driver back down to the pre-merge window state.  The
> other is to apply this series of patches, which frankly I don't think
> is -rc material, even with the above regressions.
> 
> Given that the above regressions were caused by a lack of due care and
> correct process (I had declared to TI that I had investigated these
> issues back in April), I believe that the right answer is to revert at
> least commit 957ee7270d, which should re-hide these other bugs in the
> driver.

Note: these patches are not as well validated as my previous set; I
haven't even build-tested just this set, but only my full set.  YMMV.