linux-stable.git/drivers/tty, branch v5.4.13

tty: serial: pch_uart: correct usage of dma_unmap_sg

2020-01-17T18:48:55+00:00

commit 74887542fdcc92ad06a48c0cca17cdf09fc8aa00 upstream.

Per Documentation/DMA-API-HOWTO.txt,
To unmap a scatterlist, just call:
	dma_unmap_sg(dev, sglist, nents, direction);

.. note::

	The 'nents' argument to the dma_unmap_sg call must be
	the _same_ one you passed into the dma_map_sg call,
	it should _NOT_ be the 'count' value _returned_ from the
	dma_map_sg call.

However in the driver, priv->nent is directly assigned with value
returned from dma_map_sg, and dma_unmap_sg use priv->nent for unmap,
this breaks the API usage.

So introduce a new entry orig_nent to remember 'nents'.

Fixes: da3564ee027e ("pch_uart: add multi-scatter processing")
Signed-off-by: Peng Fan 
Link: https://lore.kernel.org/r/1573623259-6339-1-git-send-email-peng.fan@nxp.com
Signed-off-by: Greg Kroah-Hartman

tty: serial: imx: use the sg count from dma_map_sg

2020-01-17T18:48:55+00:00

commit 596fd8dffb745afcebc0ec6968e17fe29f02044c upstream.

The dmaengine_prep_slave_sg needs to use sg count returned
by dma_map_sg, not use sport->dma_tx_nents, because the return
value of dma_map_sg is not always same with "nents".

Fixes: b4cdc8f61beb ("serial: imx: add DMA support for imx6q")
Signed-off-by: Peng Fan 
Link: https://lore.kernel.org/r/1573108875-26530-1-git-send-email-peng.fan@nxp.com
Signed-off-by: Greg Kroah-Hartman

tty: always relink the port

2020-01-14T19:08:33+00:00

commit 273f632912f1b24b642ba5b7eb5022e43a72f3b5 upstream.

If the serial device is disconnected and reconnected, it re-enumerates
properly but does not link it. fwiw, linking means just saving the port
index, so allow it always as there is no harm in saving the same value
again even if it tries to relink with the same port.

Fixes: fb2b90014d78 ("tty: link tty and port before configuring it as console")
Reported-by: Kenneth R. Crudup 
Signed-off-by: Sudip Mukherjee 
Cc: stable 
Link: https://lore.kernel.org/r/20191227174434.12057-1-sudipm.mukherjee@gmail.com
Signed-off-by: Greg Kroah-Hartman

tty: link tty and port before configuring it as console

2020-01-14T19:08:33+00:00

commit fb2b90014d782d80d7ebf663e50f96d8c507a73c upstream.

There seems to be a race condition in tty drivers and I could see on
many boot cycles a NULL pointer dereference as tty_init_dev() tries to
do 'tty->port->itty = tty' even though tty->port is NULL.
'tty->port' will be set by the driver and if the driver has not yet done
it before we open the tty device we can get to this situation. By adding
some extra debug prints, I noticed that:

6.650130: uart_add_one_port
6.663849: register_console
6.664846: tty_open
6.674391: tty_init_dev
6.675456: tty_port_link_device

uart_add_one_port() registers the console, as soon as it registers, the
userspace tries to use it and that leads to tty_open() but
uart_add_one_port() has not yet done tty_port_link_device() and so
tty->port is not yet configured when control reaches tty_init_dev().

Further look into the code and tty_port_link_device() is done by
uart_add_one_port(). After registering the console uart_add_one_port()
will call tty_port_register_device_attr_serdev() and
tty_port_link_device() is called from this.

Call add tty_port_link_device() before uart_configure_port() is done and
add a check in tty_port_link_device() so that it only links the port if
it has not been done yet.

Suggested-by: Jiri Slaby 
Signed-off-by: Sudip Mukherjee 
Cc: stable 
Link: https://lore.kernel.org/r/20191212131602.29504-1-sudipm.mukherjee@gmail.com
Signed-off-by: Greg Kroah-Hartman

serdev: Don't claim unsupported ACPI serial devices

2020-01-14T19:08:32+00:00

commit c5ee0b3104e0b292d353e63fd31cb8c692645d8c upstream.

Serdev sub-system claims all ACPI serial devices that are not already
initialised. As a result, no device node is created for serial ports
on certain boards such as the Apollo Lake based UP2. This has the
unintended consequence of not being able to raise the login prompt via
serial connection.

Introduce a blacklist to reject ACPI serial devices that should not be
claimed by serdev sub-system. Add the peripheral ids for Intel HS UART
to the blacklist to bring back serial port on SoCs carrying them.

Cc: stable@vger.kernel.org
Signed-off-by: Punit Agrawal 
Acked-by: Hans de Goede 
Acked-by: Johan Hovold 
Cc: Rob Herring 
Link: https://lore.kernel.org/r/20191219100345.911093-1-punit1.agrawal@toshiba.co.jp
Signed-off-by: Greg Kroah-Hartman

tty: serial: msm_serial: Fix lockup for sysrq and oops

2020-01-09T09:20:05+00:00

commit 0e4f7f920a5c6bfe5e851e989f27b35a0cc7fb7e upstream.

As the commit 677fe555cbfb ("serial: imx: Fix recursive locking bug")
has mentioned the uart driver might cause recursive locking between
normal printing and the kernel debugging facilities (e.g. sysrq and
oops).  In the commit it gave out suggestion for fixing recursive
locking issue: "The solution is to avoid locking in the sysrq case
and trylock in the oops_in_progress case."

This patch follows the suggestion (also used the exactly same code with
other serial drivers, e.g. amba-pl011.c) to fix the recursive locking
issue, this can avoid stuck caused by deadlock and print out log for
sysrq and oops.

Fixes: 04896a77a97b ("msm_serial: serial driver for MSM7K onboard serial peripheral.")
Signed-off-by: Leo Yan 
Reviewed-by: Jeffrey Hugo 
Link: https://lore.kernel.org/r/20191127141544.4277-2-leo.yan@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

serial: sprd: Add clearing break interrupt operation

2019-12-31T15:46:11+00:00

commit abeb2e9414d7e3a0d8417bc3b13d7172513ea8a0 upstream.

A break interrupt will be generated if the RX line was pulled low, which
means some abnomal behaviors occurred of the UART. In this case, we still
need to clear this break interrupt status, otherwise it will cause irq
storm to crash the whole system.

Fixes: b7396a38fb28 ("tty/serial: Add Spreadtrum sc9836-uart driver support")
Signed-off-by: Yonghan Ye 
Cc: stable 
Signed-off-by: Baolin Wang 
Link: https://lore.kernel.org/r/925e51b73099c90158e080b8f5bed9b3b38c4548.1575460601.git.baolin.wang7@gmail.com
Signed-off-by: Greg Kroah-Hartman

tty/serial: atmel: fix out of range clock divider handling

2019-12-31T15:46:11+00:00

commit cb47b9f8630ae3fa3f5fbd0c7003faba7abdf711 upstream.

Use MCK_DIV8 when the clock divider is > 65535. Unfortunately the mode
register was already written thus the clock selection is ignored.

Fix by doing the baud rate calulation before setting the mode.

Fixes: 5bf5635ac170 ("tty/serial: atmel: add fractional baud rate support")
Signed-off-by: David Engraf 
Acked-by: Ludovic Desroches 
Acked-by: Richard Genoud 
Cc: stable 
Link: https://lore.kernel.org/r/20191216085403.17050-1-david.engraf@sysgo.com
Signed-off-by: Greg Kroah-Hartman

Revert "serial/8250: Add support for NI-Serial PXI/PXIe+485 devices"

2019-12-13T07:43:22+00:00

commit 27ed14d0ecb38516b6f3c6fdcd62c25c9454f979 upstream.

This reverts commit fdc2de87124f5183a98ea7eced1f76dbdba22951 ("serial/8250:
Add support for NI-Serial PXI/PXIe+485 devices").

The commit fdc2de87124f ("serial/8250: Add support for NI-Serial
PXI/PXIe+485 devices") introduced a breakage on NI-Serial PXI(e)-RS485
devices, RS-232 variants have no issue. The Linux system can enumerate the
NI-Serial PXI(e)-RS485 devices, but it broke the R/W operation on the
ports.

However, the implementation is working on the NI internal Linux RT kernel
but it does not work in the Linux main tree kernel. This is only affecting
NI products, specifically the RS-485 variants. Reverting the upstream
until a proper implementation that can apply to both NI internal Linux
kernel and Linux mainline kernel is figured out.

Signed-off-by: Je Yen Tam 
Fixes: fdc2de87124f ("serial/8250: Add support for NI-Serial PXI/PXIe+485 devices")
Cc: stable 
Link: https://lore.kernel.org/r/20191127075301.9866-1-je.yen.tam@ni.com
Signed-off-by: Greg Kroah-Hartman

vcs: prevent write access to vcsu devices

2019-12-13T07:43:22+00:00

commit 0c9acb1af77a3cb8707e43f45b72c95266903cee upstream.

Commit d21b0be246bf ("vt: introduce unicode mode for /dev/vcs") guarded
against using devices containing attributes as this is not yet
implemented. It however failed to guard against writes to any devices
as this is also unimplemented.

Reported-by: Or Cohen 
Signed-off-by: Nicolas Pitre 
Cc:  # v4.19+
Cc: Jiri Slaby 
Fixes: d21b0be246bf ("vt: introduce unicode mode for /dev/vcs")
Link: https://lore.kernel.org/r/nycvar.YSQ.7.76.1911051030580.30289@knanqh.ubzr
Signed-off-by: Greg Kroah-Hartman