linux-stable.git/drivers/tty, branch v4.2.2

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

2015-09-21T17:10:54+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:10:54+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:10:54+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:10:54+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:10:54+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:10:53+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

tty: serial: 8250_omap: do not use RX DMA if pause is not supported

2015-09-21T17:10:49+00:00

commit 830acf9e3044d4644f91b4418ef35a2094089946 upstream.

The 8250-omap driver requires the DMA-engine driver to support the pause
command in order to properly turn off programmed RX transfer before the
driver stars manually reading from the FIFO.
The lacking support of the requirement has been discovered recently. In
order to stay safe here we disable RX-DMA completly on probe.
The rx_dma_broken assignment on probe could be removed once we working
pause function in omap-dma.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_uniphier: call clk_disable_unprepare() on failure path

2015-09-21T17:10:49+00:00

commit e70e69bf205e6d1f742f1cf1935b155417c9e29a upstream.

If serial8250_register_8250_port() fails, disable and unprepare the
clock before exiting.

Fixes: 1a8d2903cb6a ("serial: 8250_uniphier: add UniPhier serial driver")
Signed-off-by: Masahiro Yamada 
Reviewed-by: Matthias Brugger 
Signed-off-by: Greg Kroah-Hartman

tty: vt: Fix !TASK_RUNNING diagnostic warning from paste_selection()

2015-07-24T01:08:29+00:00

Pasting text with gpm on a VC produced warning [1]. Reset task state
to TASK_RUNNING in the paste_selection() loop, if the loop did not
sleep.

[1]
WARNING: CPU: 6 PID: 1960 at /home/peter/src/kernels/mainline/kernel/sched/core.c:7286 __might_sleep+0x7f/0x90()
do not call blocking ops when !TASK_RUNNING; state=1 set at [] paste_selection+0x9e/0x1a0
Modules linked in: btrfs xor raid6_pq ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c .....
CPU: 6 PID: 1960 Comm: gpm Not tainted 4.1.0-rc7+tty-xeon+debug #rc7+tty
Hardware name: Dell Inc. Precision WorkStation T5400  /0RW203, BIOS A11 04/30/2012
 ffffffff81c9c0a0 ffff8802b0fd3ac8 ffffffff8185778a 0000000000000001
 ffff8802b0fd3b18 ffff8802b0fd3b08 ffffffff8108039a ffffffff82ae8510
 ffffffff81c9ce00 0000000000000015 0000000000000000 0000000000000000
Call Trace:
 [] dump_stack+0x4f/0x7b
 [] warn_slowpath_common+0x8a/0xc0
 [] warn_slowpath_fmt+0x46/0x50
 [] ? __lock_acquire+0xe2d/0x13a0
 [] ? paste_selection+0x9e/0x1a0
 [] ? paste_selection+0x9e/0x1a0
 [] __might_sleep+0x7f/0x90
 [] down_read+0x2a/0xa0
 [] ? sched_clock_cpu+0xb8/0xe0
 [] n_tty_receive_buf_common+0x4c/0xba0
 [] ? mark_held_locks+0x75/0xa0
 [] ? _raw_spin_unlock_irqrestore+0x65/0x80
 [] ? get_parent_ip+0x11/0x50
 [] n_tty_receive_buf2+0x14/0x20
 [] paste_selection+0x157/0x1a0
 [] ? wake_up_state+0x20/0x20
 [] tioclinux+0xb8/0x2c0
 [] vt_ioctl+0xaee/0x11a0
 [] ? sched_clock_local+0x25/0x90
 [] ? vtime_account_user+0x91/0xa0
 [] tty_ioctl+0x20c/0xe20
 [] ? vtime_account_user+0x91/0xa0
 [] ? get_parent_ip+0x11/0x50
 [] ? preempt_count_sub+0x49/0x50
 [] ? context_tracking_exit+0x5c/0x290
 [] ? context_tracking_exit+0x5c/0x290
 [] do_vfs_ioctl+0x318/0x570
 [] ? trace_hardirqs_on+0xd/0x10
 [] ? trace_hardirqs_on_caller+0x115/0x1e0
 [] ? __fget_light+0x6c/0xa0
 [] SyS_ioctl+0x81/0xa0
 [] system_call_fastpath+0x16/0x7a

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

serial: core: Fix crashes while echoing when closing

2015-07-24T01:08:28+00:00

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