linux-toradex.git/drivers/tty, branch v4.1.13

serial: 8250_pci: Add support for 12 port Exar boards

2015-11-09T22:33:40+00:00

commit be32c0cf0462c36f482b5ddcff1d8371be1e183c upstream.

The Exar XR17V358 can also be combined with a XR17V354 chip to act as a
single 12 port chip. This works the same way as the combining two XR17V358
chips. But the reported device id then is 0x4358.

Signed-off-by: Soeren Grunewald 
Signed-off-by: Greg Kroah-Hartman

Revert "serial: 8250_dma: don't bother DMA with small transfers"

2015-11-09T22:33:37+00:00

commit f967fc8f165fadb72166f2bd4785094b3ca21307 upstream.

This reverts commit 9119fba0cfeda6d415c9f068df66838a104b87cb.

This commit prevents from sending "big" file using Bluetooth.
When sending a lot of data quickly through the Bluetooth interface, and
after a variable amount of data sent, transfer fails with error:
    kernel: [  415.247453] Bluetooth: hci0 hardware error 0x00

Found on T100TA.

After reverting this commit, send works fine for any file size.

Signed-off-by: Frederic Danis 
Fixes: 9119fba0cfed (serial: 8250_dma: don't bother DMA with small transfers)
Reviewed-by: Heikki Krogerus 
Acked-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

serial: atmel: fix error path of probe function

2015-10-22T21:43:27+00:00

commit 8f1bd8f2ad2358d6a88c115481ff3e69817d1bde upstream.

If atmel_init_gpios fails the port has already been marked as busy (in
line 2629), so this must be undone in the error path.

This bug was introduced because I created the patch that finally
became 722ccf416ac2 ("serial: atmel: fix error handling when
mctrl_gpio_init fails") on top of 3.19 which didn't have commit
6fbb9bdf0f3f ("tty/serial: at91: fix error handling in
atmel_serial_probe()") yet.

Signed-off-by: Uwe Kleine-König 
Fixes: 722ccf416ac2 ("serial: atmel: fix error handling when mctrl_gpio_init fails")
Acked-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman

serial: 8250: add uart_config entry for PORT_RT2880

2015-10-22T21:43:27+00:00

commit 3c5a0357fdb3a9116a48dbdb0abb91fd23fbff80 upstream.

This adds an entry to the uart_config table for PORT_RT2880
enabling rx/tx FIFOs.  The UART is actually a Palmchip BK-3103
which is found in several devices from Alchemy/RMI, Ralink, and
Sigma Designs.

Signed-off-by: Mans Rullgard 
Signed-off-by: Greg Kroah-Hartman

drivers/tty: require read access for controlling terminal

2015-10-22T21:43:26+00:00

commit 0c55627167870255158db1cde0d28366f91c8872 upstream.

This is mostly a hardening fix, given that write-only access to other
users' ttys is usually only given through setgid tty executables.

Signed-off-by: Jann Horn 
Signed-off-by: Greg Kroah-Hartman

tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c

2015-10-22T21:43:26+00:00

commit e81107d4c6bd098878af9796b24edc8d4a9524fd upstream.

My colleague ran into a program stall on a x86_64 server, where
n_tty_read() was waiting for data even if there was data in the buffer
in the pty.  kernel stack for the stuck process looks like below.
 #0 [ffff88303d107b58] __schedule at ffffffff815c4b20
 #1 [ffff88303d107bd0] schedule at ffffffff815c513e
 #2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818
 #3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2
 #4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23
 #5 [ffff88303d107dd0] tty_read at ffffffff81368013
 #6 [ffff88303d107e20] __vfs_read at ffffffff811a3704
 #7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57
 #8 [ffff88303d107f00] sys_read at ffffffff811a4306
 #9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7

There seems to be two problems causing this issue.

First, in drivers/tty/n_tty.c, __receive_buf() stores the data and
updates ldata->commit_head using smp_store_release() and then checks
the wait queue using waitqueue_active().  However, since there is no
memory barrier, __receive_buf() could return without calling
wake_up_interactive_poll(), and at the same time, n_tty_read() could
start to wait in wait_woken() as in the following chart.

        __receive_buf()                         n_tty_read()
------------------------------------------------------------------------
if (waitqueue_active(&tty->read_wait))
/* Memory operations issued after the
   RELEASE may be completed before the
   RELEASE operation has completed */
                                        add_wait_queue(&tty->read_wait, &wait);
                                        ...
                                        if (!input_available_p(tty, 0)) {
smp_store_release(&ldata->commit_head,
                  ldata->read_head);
                                        ...
                                        timeout = wait_woken(&wait,
                                          TASK_INTERRUPTIBLE, timeout);
------------------------------------------------------------------------

The second problem is that n_tty_read() also lacks a memory barrier
call and could also cause __receive_buf() to return without calling
wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken()
as in the chart below.

        __receive_buf()                         n_tty_read()
------------------------------------------------------------------------
                                        spin_lock_irqsave(&q->lock, flags);
                                        /* from add_wait_queue() */
                                        ...
                                        if (!input_available_p(tty, 0)) {
                                        /* Memory operations issued after the
                                           RELEASE may be completed before the
                                           RELEASE operation has completed */
smp_store_release(&ldata->commit_head,
                  ldata->read_head);
if (waitqueue_active(&tty->read_wait))
                                        __add_wait_queue(q, wait);
                                        spin_unlock_irqrestore(&q->lock,flags);
                                        /* from add_wait_queue() */
                                        ...
                                        timeout = wait_woken(&wait,
                                          TASK_INTERRUPTIBLE, timeout);
------------------------------------------------------------------------

There are also other places in drivers/tty/n_tty.c which have similar
calls to waitqueue_active(), so instead of adding many memory barrier
calls, this patch simply removes the call to waitqueue_active(),
leaving just wake_up*() behind.

This fixes both problems because, even though the memory access before
or after the spinlocks in both wake_up*() and add_wait_queue() can
sneak into the critical section, it cannot go past it and the critical
section assures that they will be serialized (please see "INTER-CPU
ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
better explanation).  Moreover, the resulting code is much simpler.

Latency measurement using a ping-pong test over a pty doesn't show any
visible performance drop.

Signed-off-by: Kosuke Tatsukawa 
Signed-off-by: Greg Kroah-Hartman

serial/amba-pl011: Disable interrupts around TX softirq

2015-10-22T21:43:20+00:00

pl011_tx_softirq() currently uses spin_{,un}lock(), which are not
sufficient to inhibit pl011_int() from being triggered by a local
IRQ and trying to re-take the same lock.  This can lead to
deadlocks.

This patch uses the _irq() locking variants instead to ensure that
pl011_int() handling for a given port is deferred until any
pl011_tx_softirq() work for that port is complete.


Notes for stable:

This patch fixes an issue that is fixed by the following upstream
commit, which is a more substantial rewrite of the affected code,
fixing multiple, mostly more minor issues:

        1e84d22322ceed4767db1e5342c830dd60c8210f
        serial/amba-pl011: Refactor and simplify TX FIFO handling

The upstream patch was rejected for stable on the reasonable grounds
that it was too big and complex a patch.  The original buggy code was
merged in v4.1, and the rewrite was merged in v4.2, leaving only v4.1
affected.


This patch replaces the 1e84d22, for 4.1.x only.

Fixes: 734745caeb9f serial/amba-pl011: Activate TX IRQ passively
Signed-off-by: Dave Martin 
Tested-by: Robin Murphy 
Tested-by: Stefan Wahren 
Signed-off-by: Greg Kroah-Hartman

serial: samsung: fix DMA for FIFO smaller than cache line size

2015-09-21T17:05:40+00:00

commit 736cd79f483fd7a1e0b71e6eaddf01d8d87fbbbb upstream.

So far DMA mode were activated when only number of bytes to send was
equal or greater than min_dma_size. Due to requirement that DMA transaction
buffer should be aligned to cache line size, the excessive bytes were
written to FIFO before starting DMA transaction. The problem occurred
when FIFO size were smaller than cache alignment, because writing all
excessive bytes to FIFO would fail. It happened in DMA mode when PIO
interrupts disabled, which caused driver hung.

The solution is to test if buffer is alligned to cache line size before
activating DMA mode, and if it's not, running PIO mode to align buffer
and then starting DMA transaction. In PIO mode, when interrupts are
enabled, lack of space in FIFO isn't the problem, so buffer aligning
will always finish with success.

Reported-by: Krzysztof Kozlowski 
Signed-off-by: Robert Baldyga 
Signed-off-by: Greg Kroah-Hartman

serial: samsung: fix DMA mode enter condition for small FIFO sizes

2015-09-21T17:05:40+00:00

commit 81ccb2a69f76b88295a1da9fc9484df715fe3bfa upstream.

Due to some of serial ports can have FIFO size smaller than cache line
size, and because of need to align DMA buffer address to cache line size,
it's necessary to calculate minimum number of bytes for which we want
to start DMA transaction to be at least cache line size. The simplest
way to meet this requirement is to get maximum of cache line size and
FIFO size.

Reported-by: Krzysztof Kozlowski 
Signed-off-by: Marek Szyprowski 
Signed-off-by: Robert Baldyga 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: Add support for Pericom PI7C9X795[1248]

2015-09-21T17:05:39+00:00

commit 89c043a6cb2d4525d48a38ed78d5f0f5672338b3 upstream.

Pericom PI7C9X795[1248] are Uno/Dual/Quad/Octal UART devices, this
patch enables them, also defines PCI_VENDOR_ID_PERICOM here.

Signed-off-by: Adam Lee 
Signed-off-by: Greg Kroah-Hartman