linux-toradex.git/drivers/tty, branch v3.10.51

serial: 8250_dw: Fix LCR workaround regression

2014-07-09T18:14:02+00:00

commit 6979f8d28049879e6147767d93ba6732c8bd94f4 upstream.

Commit c49436b657d0 (serial: 8250_dw: Improve unwritable LCR workaround)
caused a regression. It added a check that the LCR was written properly
to detect and workaround the busy quirk, but the behaviour of bit 5
(UART_LCR_SPAR) differs between IP versions 3.00a and 3.14c per the
docs. On older versions this caused the check to fail and it would
repeatedly force idle and rewrite the LCR register, causing delays and
preventing any input from serial being received.

This is fixed by masking out UART_LCR_SPAR before making the comparison.

Signed-off-by: James Hogan 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Tim Kryger 
Cc: Ezequiel Garcia 
Cc: Matt Porter 
Cc: Markus Mayer 
Tested-by: Tim Kryger 
Tested-by: Ezequiel Garcia 
Tested-by: Heikki Krogerus 
Cc: Wang Nan 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Improve unwritable LCR workaround

2014-07-09T18:14:02+00:00

commit c49436b657d0a56a6ad90d14a7c3041add7cf64d upstream.

When configured with UART_16550_COMPATIBLE=NO or in versions prior to
the introduction of this option, the Designware UART will ignore writes
to the LCR if the UART is busy.  The current workaround saves a copy of
the last written LCR and re-writes it in the ISR for a special interrupt
that is raised when a write was ignored.

Unfortunately, interrupts are typically disabled prior to performing a
sequence of register writes that include the LCR so the point at which
the retry occurs is too late.  An example is serial8250_do_set_termios()
where an ignored LCR write results in the baud divisor not being set and
instead a garbage character is sent out the transmitter.

Furthermore, since serial_port_out() offers no way to indicate failure,
a serious effort must be made to ensure that the LCR is actually updated
before returning back to the caller.  This is difficult, however, as a
UART that was busy during the first attempt is likely to still be busy
when a subsequent attempt is made unless some extra action is taken.

This updated workaround reads back the LCR after each write to confirm
that the new value was accepted by the hardware.  Should the hardware
ignore a write, the TX/RX FIFOs are cleared and the receive buffer read
before attempting to rewrite the LCR out of the hope that doing so will
force the UART into an idle state.  While this may seem unnecessarily
aggressive, writes to the LCR are used to change the baud rate, parity,
stop bit, or data length so the data that may be lost is likely not
important.  Admittedly, this is far from ideal but it seems to be the
best that can be done given the hardware limitations.

Lastly, the revised workaround doesn't touch the LCR in the ISR, so it
avoids the possibility of a "serial8250: too much work for irq" lock up.
This problem is rare in real situations but can be reproduced easily by
wiring up two UARTs and running the following commands.

  # stty -F /dev/ttyS1 echo
  # stty -F /dev/ttyS2 echo
  # cat /dev/ttyS1 &
  [1] 375
  # echo asdf > /dev/ttyS1
  asdf

  [   27.700000] serial8250: too much work for irq96
  [   27.700000] serial8250: too much work for irq96
  [   27.710000] serial8250: too much work for irq96
  [   27.710000] serial8250: too much work for irq96
  [   27.720000] serial8250: too much work for irq96
  [   27.720000] serial8250: too much work for irq96
  [   27.730000] serial8250: too much work for irq96
  [   27.730000] serial8250: too much work for irq96
  [   27.740000] serial8250: too much work for irq96

Signed-off-by: Tim Kryger 
Reviewed-by: Matt Porter 
Reviewed-by: Markus Mayer 
Reviewed-by: Heikki Krogerus 
[wangnan: backport to 3.10.43:
  - adjust context
  - remove unneeded local var]
Signed-off-by: Wang Nan 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Report CTS asserted for auto flow

2014-07-09T18:14:02+00:00

commit 33acbb82695f84e9429c1f7fbdeb4588dea12ffa upstream.

When a serial port is configured for RTS/CTS flow control, serial core
will disable the transmitter if it observes CTS is de-asserted. This is
perfectly reasonable and appropriate when the UART lacks the ability to
automatically perform CTS flow control.

However, if the UART hardware can manage flow control automatically, it
is important that software not get involved.  When the DesignWare UART
enables 16C750 style auto-RTS/CTS it stops generating interrupts for
changes in CTS state so software mostly stays out of the way.  However,
it does report the true state of CTS in the MSR so software may notice
it is de-asserted and respond by improperly disabling the transmitter.
Once this happens the transmitter will be blocked forever.

To avoid this situation, we simply lie to the 8250 and serial core by
reporting that CTS is asserted whenever auto-RTS/CTS mode is enabled.

Signed-off-by: Tim Kryger 
Reviewed-by: Matt Porter 
Reviewed-by: Markus Mayer 
Cc: Wang Nan 
Signed-off-by: Greg Kroah-Hartman

8250_core: Fix unwanted TX chars write

2014-06-07T20:25:30+00:00

commit b08c9c317e3f7764a91d522cd031639ba42b98cc upstream.

On transmit-hold-register empty, serial8250_tx_chars
should be called only if we don't use DMA.
DMA has its own tx cycle.

Signed-off-by: Loic Poulain 
Reviewed-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Fix thread unsafe __dma_tx_complete function

2014-06-07T20:25:30+00:00

commit f8fd1b0350d3a4581125f5eda6528f5a2c5f9183 upstream.

__dma_tx_complete is not protected against concurrent
call of serial8250_tx_dma. it can lead to circular tail
index corruption or parallel call of serial_tx_dma on the
same data portion.

This patch fixes this issue by holding the port lock.

Signed-off-by: Loic Poulain 
Reviewed-by: Heikki Krogerus 
Signed-off-by: Greg Kroah-Hartman

n_tty: Fix n_tty_write crash when echoing in raw mode

2014-05-13T11:59:40+00:00

commit 4291086b1f081b869c6d79e5b7441633dc3ace00 upstream.

The tty atomic_write_lock does not provide an exclusion guarantee for
the tty driver if the termios settings are LECHO & !OPOST.  And since
it is unexpected and not allowed to call TTY buffer helpers like
tty_insert_flip_string concurrently, this may lead to crashes when
concurrect writers call pty_write. In that case the following two
writers:
* the ECHOing from a workqueue and
* pty_write from the process
race and can overflow the corresponding TTY buffer like follows.

If we look into tty_insert_flip_string_fixed_flag, there is:
  int space = __tty_buffer_request_room(port, goal, flags);
  struct tty_buffer *tb = port->buf.tail;
  ...
  memcpy(char_buf_ptr(tb, tb->used), chars, space);
  ...
  tb->used += space;

so the race of the two can result in something like this:
              A                                B
__tty_buffer_request_room
                                  __tty_buffer_request_room
memcpy(buf(tb->used), ...)
tb->used += space;
                                  memcpy(buf(tb->used), ...) ->BOOM

B's memcpy is past the tty_buffer due to the previous A's tb->used
increment.

Since the N_TTY line discipline input processing can output
concurrently with a tty write, obtain the N_TTY ldisc output_lock to
serialize echo output with normal tty writes.  This ensures the tty
buffer helper tty_insert_flip_string is not called concurrently and
everything is fine.

Note that this is nicely reproducible by an ordinary user using
forkpty and some setup around that (raw termios + ECHO). And it is
present in kernels at least after commit
d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to
use the normal buffering logic) in 2.6.31-rc3.

js: add more info to the commit log
js: switch to bool
js: lock unconditionally
js: lock only the tty->ops->write call

References: CVE-2014-0196
Reported-and-tested-by: Jiri Slaby 
Signed-off-by: Peter Hurley 
Signed-off-by: Jiri Slaby 
Cc: Linus Torvalds 
Cc: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

tty: serial: 8250_core.c Bug fix for Exar chips.

2014-05-13T11:59:40+00:00

commit b790f210fe8423eff881b2a8a93ba5dbc45534d0 upstream.

The sleep function was updated to put the serial port to sleep only when necessary.
This appears to resolve the errant behavior of the driver as described in
Kernel Bug 61961 – "My Exar Corp. XR17C/D152 Dual PCI UART modem does not
work with 3.8.0".

Signed-off-by: Michael Welling 
Signed-off-by: Greg Kroah-Hartman

drivers/tty/hvc: don't free hvc_console_setup after init

2014-05-13T11:59:40+00:00

commit 501fed45b7e8836ee9373f4d31e2d85e3db6103a upstream.

When 'console=hvc0' is specified to the kernel parameter in x86 KVM guest,
hvc console is setup within a kthread. However, that will cause SEGV
and the boot will fail when the driver is builtin to the kernel,
because currently hvc_console_setup() is annotated with '__init'. This
patch removes '__init' to boot the guest successfully with 'console=hvc0'.

Signed-off-by: Tomoki Sekiyama 
Signed-off-by: Greg Kroah-Hartman

hvc: ensure hvc_init is only ever called once in hvc_console.c

2014-05-06T14:55:32+00:00

commit f76a1cbed18c86e2d192455f0daebb48458965f3 upstream.

Commit 3e6c6f630a5282df8f3393a59f10eb9c56536d23 ("Delay creation of
khcvd thread") moved the call of hvc_init from being a device_initcall
into hvc_alloc, and used a non-null hvc_driver as indication of whether
hvc_init had already been called.

The problem with this is that hvc_driver is only assigned a value
at the bottom of hvc_init, and so there is a window where multiple
hvc_alloc calls can be in progress at the same time and hence try
and call hvc_init multiple times.  Previously the use of device_init
guaranteed that hvc_init was only called once.

This manifests itself as sporadic instances of two hvc_init calls
racing each other, and with the loser of the race getting -EBUSY
from tty_register_driver() and hence that virtual console fails:

    Couldn't register hvc console driver
    virtio-ports vport0p1: error -16 allocating hvc for port

Here we add an atomic_t to guarantee we'll never run hvc_init twice.

Cc: Rusty Russell 
Cc: Greg Kroah-Hartman 
Fixes: 3e6c6f630a52 ("Delay creation of khcvd thread")
Reported-by: Jim Somerville 
Tested-by: Jim Somerville 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Greg Kroah-Hartman

tty: Set correct tty name in 'active' sysfs attribute

2014-04-27T00:15:34+00:00

commit 723abd87f6e536f1353c8f64f621520bc29523a3 upstream.

The 'active' sysfs attribute should refer to the currently active tty
devices the console is running on, not the currently active console. The
console structure doesn't refer to any device in sysfs, only the tty the
console is running on has. So we need to print out the tty names in
'active', not the console names.

There is one special-case, which is tty0. If the console is directed to
it, we want 'tty0' to show up in the file, so user-space knows that the
messages get forwarded to the active VT. The ->device() callback would
resolve tty0, though. Hence, treat it special and don't call into the VT
layer to resolve it (plymouth is known to depend on it).

Cc: Lennart Poettering 
Cc: Kay Sievers 
Cc: Jiri Slaby 
Signed-off-by: Werner Fink 
Signed-off-by: Hannes Reinecke 
Signed-off-by: David Herrmann 
Signed-off-by: Greg Kroah-Hartman