linux-stable.git/drivers/tty/serial, branch v3.16.40

serial: 8250: added acces i/o products quad and octal serial cards

2016-11-20T01:17:20+00:00

commit c8d192428f52f244130b84650ad616df09f2b1e1 upstream.

Added devices ids for acces i/o products quad and octal serial cards
that make use of existing Pericom PI7C9X7954 and PI7C9X7958
configurations .

Signed-off-by: Jimi Damon 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

sparc: serial: sunhv: fix a double lock bug

2016-11-20T01:16:59+00:00

commit 344e3c7734d5090b148c19ac6539b8947fed6767 upstream.

We accidentally take the "port->lock" twice in a row.  This old code
was supposed to be deleted.

Fixes: e58e241c1788 ('sparc: serial: Clean up the locking for -rt')
Signed-off-by: Dan Carpenter 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

serial: samsung: Fix possible out of bounds access on non-DT platform

2016-11-20T01:16:42+00:00

commit 926b7b5122c96e1f18cd20e85a286c7ec8d18c97 upstream.

On non-DeviceTree platforms, the index of serial device is a static
variable incremented on each probe.  It is incremented even if deferred
probe happens when getting the clock in s3c24xx_serial_init_port().

This index is used for referencing elements of statically allocated
s3c24xx_serial_ports array.  In case of re-probe, the index will point
outside of this array leading to memory corruption.

Increment the index only on successful probe.

Reported-by: Bartlomiej Zolnierkiewicz 
Fixes: b497549a035c ("[ARM] S3C24XX: Split serial driver into core and per-cpu drivers")
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

serial: samsung: Fix ERR pointer dereference on deferred probe

2016-11-20T01:16:42+00:00

commit e51e4d8a185de90424b03f30181b35f29c46a25a upstream.

When the clk_get() of "uart" clock returns EPROBE_DEFER, the next re-probe
finishes with success but uses invalid (ERR_PTR) values.  This leads to
dereferencing of ERR_PTR stored under ourport->clk:

	12c30000.serial: Controller clock not found
	(...)
	12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 61, base_baud = 0) is a S3C6400/10
	Unable to handle kernel paging request at virtual address fffffdfb

	(clk_prepare) from [] (s3c24xx_serial_pm+0x20/0x128)
	(s3c24xx_serial_pm) from [] (uart_change_pm+0x38/0x40)
	(uart_change_pm) from [] (uart_add_one_port+0x31c/0x44c)
	(uart_add_one_port) from [] (s3c24xx_serial_probe+0x2a8/0x418)
	(s3c24xx_serial_probe) from [] (platform_drv_probe+0x50/0xb0)
	(platform_drv_probe) from [] (driver_probe_device+0x1f4/0x2b0)
	(driver_probe_device) from [] (bus_for_each_drv+0x44/0x8c)
	(bus_for_each_drv) from [] (__device_attach+0x9c/0x100)
	(__device_attach) from [] (bus_probe_device+0x84/0x8c)
	(bus_probe_device) from [] (deferred_probe_work_func+0x60/0x8c)
	(deferred_probe_work_func) from [] (process_one_work+0x120/0x328)
	(process_one_work) from [] (worker_thread+0x2c/0x4ac)
	(worker_thread) from [] (kthread+0xd8/0xf4)
	(kthread) from [] (ret_from_fork+0x14/0x3c)

The first unsuccessful clk_get() causes s3c24xx_serial_init_port() to
exit with failure but the s3c24xx_uart_port is left half-configured
(e.g. port->mapbase is set, clk contains ERR_PTR).  On next re-probe,
the function s3c24xx_serial_init_port() will exit early with success
because of configured port->mapbase and driver will use old values,
including the ERR_PTR as clock.

Fix this by cleaning the port->mapbase on error path so each re-probe
will initialize all of the port settings.

Fixes: 60e93575476f ("serial: samsung: enable clock before clearing pending interrupts during init")
Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
Tested-by: Kevin Hilman 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: driver doesn't set up DMA here]
Signed-off-by: Ben Hutchings

tty/serial: atmel: fix RS485 half duplex with DMA

2016-11-20T01:16:42+00:00

commit 0058f0871efe7b01c6f2b3046c68196ab73e96da upstream.

When using DMA, half duplex doesn't work properly because rx is not stopped
before starting tx. Ensure we call atmel_stop_rx() in the DMA case.

Signed-off-by: Alexandre Belloni 
Acked-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16:
 - Adjust context
 - Keep using UART_GET_PTSR()]
Signed-off-by: Ben Hutchings

serial: sh-sci: Remove cpufreq notifier to fix crash/deadlock

2016-04-30T22:06:11+00:00

commit ff1cab374ad98f4b9f408525ca9c08992b4ed784 upstream.

The BSP team noticed that there is spin/mutex lock issue on sh-sci when
CPUFREQ is used.  The issue is that the notifier function may call
mutex_lock() while the spinlock is held, which can lead to a BUG().
This may happen if CPUFREQ is changed while another CPU calls
clk_get_rate().

Taking the spinlock was added to the notifier function in commit
e552de2413edad1a ("sh-sci: add platform device private data"), to
protect the list of serial ports against modification during traversal.
At that time the Common Clock Framework didn't exist yet, and
clk_get_rate() just returned clk->rate without taking a mutex.
Note that since commit d535a2305facf9b4 ("serial: sh-sci: Require a
device per port mapping."), there's no longer a list of serial ports to
traverse, and taking the spinlock became superfluous.

To fix the issue, just remove the cpufreq notifier:
  1. The notifier doesn't work correctly: all it does is update the
     stored clock rate; it does not update the divider in the hardware.
     The divider will only be updated when calling sci_set_termios().
     I believe this was broken back in 2004, when the old
     drivers/char/sh-sci.c driver (where the notifier did update the
     divider) was replaced by drivers/serial/sh-sci.c (where the
     notifier just updated port->uartclk).
     Cfr. full-history-linux commits 6f8deaef2e9675d9 ("[PATCH] sh: port
     sh-sci driver to the new API") and 3f73fe878dc9210a ("[PATCH]
     Remove old sh-sci driver").
  2. On modern SoCs, the sh-sci parent clock rate is no longer related
     to the CPU clock rate anyway, so using a cpufreq notifier is
     futile.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Ben Hutchings

8250: use callbacks to access UART_DLL/UART_DLM

2016-04-30T22:05:46+00:00

commit 0b41ce991052022c030fd868e03877700220b090 upstream.

Some UART HW has a single register combining UART_DLL/UART_DLM
(this was probably forgotten in the change that introduced the
callbacks, commit b32b19b8ffc05cbd3bf91c65e205f6a912ca15d9)

Fixes: b32b19b8ffc0 ("[SERIAL] 8250: set divisor register correctly ...")

Signed-off-by: Sebastian Frias 
Reviewed-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

serial: omap: Prevent DoS using unprivileged ioctl(TIOCSRS485)

2016-02-25T10:34:47+00:00

commit 308bbc9ab838d0ace0298268c7970ba9513e2c65 upstream.

The omap-serial driver emulates RS485 delays using software timers,
but neglects to clamp the input values from the unprivileged
ioctl(TIOCSRS485). Because the software implementation busy-waits,
malicious userspace could stall the cpu for ~49 days.

Clamp the input values to < 100ms.

Fixes: 4a0ac0f55b18 ("OMAP: add RS485 support")
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman 
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques

serial: 8250_pci: Correct uartclk for xr17v35x expansion chips

2015-11-16T11:27:21+00:00

commit 899f0c1c7dbcc487fdc8756a49ff70b1d5d75f89 upstream.

The internal clock of the master chip, which is usually 125MHz, is only half
(62.5MHz) for the slave chips. So we have to adjust the uartclk for all the
slave ports. Therefor we add a new function to determine if a slave chip is
present and update pci_xr17v35x_setup accordingly.

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

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

2015-11-16T11:27:20+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 
Signed-off-by: Luis Henriques