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

serial: efm32: Fix parity management in 'efm32_uart_console_get_options()'

2017-06-26T05:13:09+00:00

commit be40597a1bc173bf9dadccdf5388b956f620ae8f upstream.

UARTn_FRAME_PARITY_ODD is 0x0300
UARTn_FRAME_PARITY_EVEN is 0x0200
So if the UART is configured for EVEN parity, it would be reported as ODD.
Fix it by correctly testing if the 2 bits are set.

Fixes: 3afbd89c9639 ("serial/efm32: add new driver")
Signed-off-by: Christophe JAILLET 
Acked-by: Uwe Kleine-König 
Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Fix panic when serial console and DMA are enabled

2017-06-14T11:16:26+00:00

commit 3c9101766b502a0163d1d437fada5801cf616be2 upstream.

This patch fixes an issue that kernel panic happens when DMA is enabled
and we press enter key while the kernel booting on the serial console.

* An interrupt may occur after sci_request_irq().
* DMA transfer area is initialized by setup_timer() in sci_request_dma()
  and used in interrupt.

If an interrupt occurred between sci_request_irq() and setup_timer() in
sci_request_dma(), DMA transfer area has not been initialized yet.
So, this patch changes the order of sci_request_irq() and
sci_request_dma().

Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.")
Signed-off-by: Takatoshi Akiyama 
[Shimoda changes the commit log]
Signed-off-by: Yoshihiro Shimoda 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

tty: Drop krefs for interrupted tty lock

2017-06-14T11:16:26+00:00

commit e9036d0662360cd4c79578565ce422ed5872f301 upstream.

When the tty lock is interrupted on attempted re-open, 2 tty krefs
are still held. Drop extra kref before returning failure from
tty_lock_interruptible(), and drop lookup kref before returning
failure from tty_open().

Fixes: 0bfd464d3fdd ("tty: Wait interruptibly for tty lock on reopen")
Reported-by: Dmitry Vyukov 
Signed-off-by: Peter Hurley 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

serial: ifx6x60: fix use-after-free on module unload

2017-06-14T11:16:20+00:00

commit 1e948479b3d63e3ac0ecca13cbf4921c7d17c168 upstream.

Make sure to deregister the SPI driver before releasing the tty driver
to avoid use-after-free in the SPI remove callback where the tty
devices are deregistered.

Fixes: 72d4724ea54c ("serial: ifx6x60: Add modem power off function in the platform reboot process")
Cc: Jun Chen 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

tty: pty: Fix ldisc flush after userspace become aware of the data already

2017-05-20T12:27:02+00:00

commit 77dae6134440420bac334581a3ccee94cee1c054 upstream.

While using emacs, cat or others' commands in konsole with recent
kernels, I have met many times that CTRL-C freeze konsole. After
konsole freeze I can't type anything, then I have to open a new one,
it is very annoying.

See bug report:
https://bugs.kde.org/show_bug.cgi?id=175283

The platform in that bug report is Solaris, but now the pty in linux
has the same problem or the same behavior as Solaris :)

It has high possibility to trigger the problem follow steps below:
Note: In my test, BigFile is a text file whose size is bigger than 1G
1:open konsole
1:cat BigFile
2:CTRL-C

After some digging, I find out the reason is that commit 1d1d14da12e7
("pty: Fix buffer flush deadlock") changes the behavior of pty_flush_buffer.

Thread A                                 Thread B
--------                                 --------
1:n_tty_poll return POLLIN
                                         2:CTRL-C trigger pty_flush_buffer
                                             tty_buffer_flush
                                               n_tty_flush_buffer
3:attempt to check count of chars:
  ioctl(fd, TIOCINQ, &available)
  available is equal to 0

4:read(fd, buffer, avaiable)
  return 0

5:konsole close fd

Yes, I know we could use the same patch included in the BUG report as
a workaround for linux platform too. But I think the data in ldisc is
belong to application of another side, we shouldn't clear it when we
want to flush write buffer of this side in pty_flush_buffer. So I think
it is better to disable ldisc flush in pty_flush_buffer, because its new
hehavior bring no benefit except that it mess up the behavior between
POLLIN, and TIOCINQ or FIONREAD.

Also I find no flush_buffer function in others' tty driver has the
same behavior as current pty_flush_buffer.

Fixes: 1d1d14da12e7 ("pty: Fix buffer flush deadlock")
Signed-off-by: Wang YanQing 
Signed-off-by: Greg Kroah-Hartman

serial: omap: suspend device on probe errors

2017-05-20T12:27:02+00:00

commit 77e6fe7fd2b7cba0bf2f2dc8cde51d7b9a35bf74 upstream.

Make sure to actually suspend the device before returning after a failed
(or deferred) probe.

Note that autosuspend must be disabled before runtime pm is disabled in
order to balance the usage count due to a negative autosuspend delay as
well as to make the final put suspend the device synchronously.

Fixes: 388bc2622680 ("omap-serial: Fix the error handling in the omap_serial probe")
Cc: Shubhrajyoti D 
Signed-off-by: Johan Hovold 
Acked-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

serial: omap: fix runtime-pm handling on unbind

2017-05-20T12:27:02+00:00

commit 099bd73dc17ed77aa8c98323e043613b6e8f54fc upstream.

An unbalanced and misplaced synchronous put was used to suspend the
device on driver unbind, something which with a likewise misplaced
pm_runtime_disable leads to external aborts when an open port is being
removed.

Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa024010
...
[] (serial_omap_set_mctrl) from [] (uart_update_mctrl+0x50/0x60)
[] (uart_update_mctrl) from [] (uart_shutdown+0xbc/0x138)
[] (uart_shutdown) from [] (uart_hangup+0x94/0x190)
[] (uart_hangup) from [] (__tty_hangup+0x404/0x41c)
[] (__tty_hangup) from [] (tty_vhangup+0x1c/0x20)
[] (tty_vhangup) from [] (uart_remove_one_port+0xec/0x260)
[] (uart_remove_one_port) from [] (serial_omap_remove+0x40/0x60)
[] (serial_omap_remove) from [] (platform_drv_remove+0x34/0x4c)

Fix this up by resuming the device before deregistering the port and by
suspending and disabling runtime pm only after the port has been
removed.

Also make sure to disable autosuspend before disabling runtime pm so
that the usage count is balanced and device actually suspended before
returning.

Note that due to a negative autosuspend delay being set in probe, the
unbalanced put would actually suspend the device on first driver unbind,
while rebinding and again unbinding would result in a negative
power.usage_count.

Fixes: 7e9c8e7dbf3b ("serial: omap: make sure to suspend device before remove")
Cc: Felipe Balbi 
Cc: Santosh Shilimkar 
Signed-off-by: Johan Hovold 
Acked-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

serial: samsung: Use right device for DMA-mapping calls

2017-05-20T12:27:02+00:00

commit 768d64f491a530062ddad50e016fb27125f8bd7c upstream.

Driver should provide its own struct device for all DMA-mapping calls instead
of extracting device pointer from DMA engine channel. Although this is harmless
from the driver operation perspective on ARM architecture, it is always good
to use the DMA mapping API in a proper way. This patch fixes following DMA API
debug warning:

WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1241 check_sync+0x520/0x9f4
samsung-uart 12c20000.serial: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000006df0f580] [size=64 bytes]
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00137-g07ca963 #51
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x20/0x24)
[] (show_stack) from [] (dump_stack+0x84/0xa0)
[] (dump_stack) from [] (__warn+0x14c/0x180)
[] (__warn) from [] (warn_slowpath_fmt+0x48/0x50)
[] (warn_slowpath_fmt) from [] (check_sync+0x520/0x9f4)
[] (check_sync) from [] (debug_dma_sync_single_for_device+0x88/0xc8)
[] (debug_dma_sync_single_for_device) from [] (s3c24xx_serial_start_tx_dma+0x100/0x2f8)
[] (s3c24xx_serial_start_tx_dma) from [] (s3c24xx_serial_tx_chars+0x198/0x33c)

Reported-by: Seung-Woo Kim 
Fixes: 62c37eedb74c8 ("serial: samsung: add dma reqest/release functions")
Signed-off-by: Marek Szyprowski 
Reviewed-by: Bartlomiej Zolnierkiewicz 
Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_omap: Fix probe and remove for PM runtime

2017-05-14T11:32:57+00:00

commit 4e0f5cc65098ea32a1e77baae74215b9bd5276b1 upstream.

Otherwise the interconnect related code implementing PM runtime will
produce these errors on a failed probe:

omap_uart 48066000.serial: omap_device: omap_device_enable() called from invalid state 1
omap_uart 48066000.serial: use pm_runtime_put_sync_suspend() in driver?

Note that we now also need to check for priv in omap8250_runtime_suspend()
as it has not yet been registered if probe fails. And we need to use
pm_runtime_put_sync() to properly idle the device like we already do
in omap8250_remove().

Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver")
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

8250_pci: Fix potential use-after-free in error path

2017-05-08T05:46:02+00:00

commit c130b666a9a711f985a0a44b58699ebe14bb7245 upstream.

Commit f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during
PCI error recovery") introduces a potential use-after-free in case the
pciserial_init_ports call in serial8250_io_resume fails, which may
happen if a memory allocation fails or if the .init quirk failed for
whatever reason).  If this happen, further pci_get_drvdata will return a
pointer to freed memory.

This patch reworks the PCI recovery resume hook to restore the old priv
structure in this case, which should be ok, since the ports were already
detached. Such error during recovery causes us to give up on the
recovery.

Fixes: f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during PCI error recovery")
Reported-by: Michal Suchanek 
Signed-off-by: Gabriel Krisman Bertazi 
Signed-off-by: Guilherme G. Piccoli 
Cc: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman