litmus-rt-ext-res.git/drivers/tty/serial, branch EXT-RES

serial: omap: suspend device on probe errors

2017-05-20T12:28:41+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:28:41+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:28:41+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-14T12:00:19+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:47:55+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 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_omap: Add OMAP_DMA_TX_KICK quirk for AM437x

2017-04-12T10:41:19+00:00

[ Upstream commit b6ffcf21082300519bc4f9c3d24f61207cc9eae4 ]

UART uses as EDMA as dma engine on AM437x SoC and therefore, requires
OMAP_DMA_TX_KICK quirk just like AM33xx. So, enable OMAP_DMA_TX_KICK
quirk for AM437x platform as well. While at that, drop use of
of_machine_is_compatible() and instead pass quirks via device data.

Signed-off-by: Vignesh R 
Acked-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

serial: mxs-auart: Fix baudrate calculation

2017-04-08T07:30:34+00:00

commit a6040bc610554c66088fda3608ae5d6307c548e4 upstream.

The reference manual for the i.MX28 recommends to calculate the divisor
as

	divisor = (UARTCLK * 32) / baud rate, rounded to the nearest integer

, so let's do this. For a typical setup of UARTCLK = 24 MHz and baud
rate = 115200 this changes the divisor from 6666 to 6667 and so the
actual baud rate improves from 115211.521 Bd (error ≅ 0.01 %) to
115194.240 Bd (error ≅ 0.005 %).

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Greg Kroah-Hartman

tty/serial: atmel: fix TX path in atmel_console_write()

2017-04-08T07:30:34+00:00

commit 497e1e16f45c70574dc9922c7f75c642c2162119 upstream.

A side effect of 89d8232411a8 ("tty/serial: atmel_serial: BUG: stop DMA
from transmitting in stop_tx") is that the console can be called with
TX path disabled. Then the system would hang trying to push charecters
out in atmel_console_putchar().

Signed-off-by: Nicolas Ferre 
Fixes: 89d8232411a8 ("tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx")
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

tty/serial: atmel: fix race condition (TX+DMA)

2017-04-08T07:30:34+00:00

commit 31ca2c63fdc0aee725cbd4f207c1256f5deaabde upstream.

If uart_flush_buffer() is called between atmel_tx_dma() and
atmel_complete_tx_dma(), the circular buffer has been cleared, but not
atmel_port->tx_len.
That leads to a circular buffer overflow (dumping (UART_XMIT_SIZE -
atmel_port->tx_len) bytes).

Tested-by: Nicolas Ferre 
Signed-off-by: Richard Genoud 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: Detach low-level driver during PCI error recovery

2017-03-22T11:43:39+00:00

[ Upstream commit f209fa03fc9d131b3108c2e4936181eabab87416 ]

During a PCI error recovery, like the ones provoked by EEH in the ppc64
platform, all IO to the device must be blocked while the recovery is
completed.  Current 8250_pci implementation only suspends the port
instead of detaching it, which doesn't prevent incoming accesses like
TIOCMGET and TIOCMSET calls from reaching the device.  Those end up
racing with the EEH recovery, crashing it.  Similar races were also
observed when opening the device and when shutting it down during
recovery.

This patch implements a more robust IO blockage for the 8250_pci
recovery by unregistering the port at the beginning of the procedure and
re-adding it afterwards.  Since the port is detached from the uart
layer, we can be sure that no request will make through to the device
during recovery.  This is similar to the solution used by the JSM serial
driver.

I thank Peter Hurley  for valuable input on
this one over one year ago.

Signed-off-by: Gabriel Krisman Bertazi 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman