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

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

serial: 8250: bind to ALi Fast Infrared Controller (ALI5123)

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

commit 1d7002777a8fe8188caaa98d4a8eb4ed298fcdae upstream.

This way this device can be used with irtty-sir -
at least on Toshiba Satellite A20-S103 it is not configured by default
and needs PNP activation before it starts to respond on I/O ports.

This device has actually its own driver (ali-ircc),
but this driver seems to be non-functional for a very long time
(see http://permalink.gmane.org/gmane.linux.irda.general/484
http://permalink.gmane.org/gmane.network.protocols.obex.openobex.user/943
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535070 ).

Signed-off-by: Maciej Szmigiero 
Signed-off-by: Greg Kroah-Hartman

serial: 8250: don't bind to SMSC IrCC IR port

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

commit ffa34de03bcfbfa88d8352942bc238bb48e94e2d upstream.

SMSC IrCC SIR/FIR port should not be bound to by
(legacy) serial driver so its own driver (smsc-ircc2)
can bind to it.

Signed-off-by: Maciej Szmigiero 
Signed-off-by: Greg Kroah-Hartman

tty: serial: men_z135_uart.c: Fix race between IRQ and set_termios()

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

commit 8117e347406278fd399b077add4e638cd017ae2d upstream.

Fix panic caused by a race between men_z135_intr() and men_z135_set_termios().

men_z135_intr() and men_z135_set_termios() both hold the struct uart_port::lock
spinlock, but men_z135_intr() does a spin_lock_irqsave() and
men_z135_set_termios() does a normal spin_lock(), which can lead to a deadlock
when an interrupt is called while the lock is being helt by
men_z135_set_termios().

This was discovered using a insmod, hardware looppback send/receive, rmmod
stress test.

Signed-off-by: Johannes Thumshirn 
Reviewed-by: Peter Hurley 
Cc: Andreas Werner 
Signed-off-by: Greg Kroah-Hartman

n_tty: signal and flush atomically

2015-08-10T19:21:57+00:00

commit 3b19e032295647b7be2aa3be62510db4aaeda759 upstream.

When handling signalling char, claim the termios write lock before
signalling waiting readers and writers to prevent further i/o
before flushing the echo and output buffers. This prevents a
userspace signal handler which may output from racing the terminal
flush.

Reference: Bugzilla #99351 ("Output truncated in ssh session after...")
Fixes: commit d2b6f44779d3 ("n_tty: Fix signal handling flushes")
Reported-by: Filipe Brandenburger 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

serial: core: Fix crashes while echoing when closing

2015-08-10T19:21:56+00:00

commit e144c58cad6667876173dd76977e9e6557e34941 upstream.

While closing, new rx data may be received after the input buffers
have been flushed but before stop_rx() halts receiving [1]. The
new data might not be processed by flush_to_ldisc() until after
uart_shutdown() and normal input processing is re-enabled (ie.,
tty->closing = 0). The race is outlined below:

CPU 0                         | CPU 1
                              |
uart_close()                  |
   tty_port_close_start()     |
      tty->closing = 1        |
      tty_ldisc_flush()       |
                              | => IRQ
                              |   while (LSR & data ready)
                              |      uart_insert_char()
                              |   tty_flip_buffer_push()
                              | <= EOI
   stop_rx()                  |   .
   uart_shutdown()            |   .
      free xmit.buf           |   .
   tty_port_tty_set(NULL)     |   .
   tty->closing = 0           |   .
                              | flush_to_ldisc()
                              |   n_tty_receive_buf_common()
                              |      __receive_buf()
                              |         ...
                              |         commit_echoes()
                              |            uart_flush_chars()
                              |               __uart_start()
                              | ** OOPS on port.tty deref **
   tty_ldisc_flush()          |

Input processing must be prevented from echoing (tty->closing = 1)
until _after_ the input buffers have been flushed again at the end
of uart_close().

[1] In fact, some input may actually be buffered _after_ stop_rx()
since the rx interrupt may have already triggered but not yet been
handled when stop_rx() disables rx interrupts.

Fixes: 2e758910832d ("serial: core: Flush ldisc after dropping port
mutex in uart_close()")
Reported-by: Robert Elliott 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

Revert "serial: imx: initialized DMA w/o HW flow enabled"

2015-08-10T19:21:56+00:00

commit 907eda32a36fcdb979bdb91ea097abb3dd2c23c9 upstream.

This reverts commit 068500e08dc87ea9a453cc4a500cf3ab28d0f936.

According to some tests, SDMA support is broken at least for i.MX6 without
HW flow control. Different forms of data-corruption appear either with
the ROM firmware for the SDMA controller as well as when loading Freescale
provided SDMA firmware versions 1.1 or 3.1.

Signed-off-by: David Jander 
Signed-off-by: Greg Kroah-Hartman

tty: remove platform_sysrq_reset_seq

2015-08-03T16:29:15+00:00

commit ffb6e0c9a0572f8e5f8e9337a1b40ac2ec1493a1 upstream.

The platform_sysrq_reset_seq code was intended as a way for an embedded
platform to provide its own sysrq sequence at compile time. After over two
years, nobody has started using it in an upstream kernel, and the platforms
that were interested in it have moved on to devicetree, which can be used
to configure the sequence without requiring kernel changes. The method is
also incompatible with the way that most architectures build support for
multiple platforms into a single kernel.

Now the code is producing warnings when built with gcc-5.1:

drivers/tty/sysrq.c: In function 'sysrq_init':
drivers/tty/sysrq.c:959:33: warning: array subscript is above array bounds [-Warray-bounds]
   key = platform_sysrq_reset_seq[i];

We could fix this, but it seems unlikely that it will ever be used, so
let's just remove the code instead. We still have the option to pass the
sequence either in DT, using the kernel command line, or using the
/sys/module/sysrq/parameters/reset_seq file.

Fixes: 154b7a489a ("Input: sysrq - allow specifying alternate reset sequence")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman