kernel/linux.git/drivers/tty, branch v5.2.16

tty/ldsem, locking/rwsem: Add missing ACQUIRE to read_failed sleep loop

2019-08-16T08:11:07+00:00

[ Upstream commit 952041a8639a7a3a73a2b6573cb8aa8518bc39f8 ] While reviewing rwsem down_slowpath, Will noticed ldsem had a copy of a bug we just found for rwsem. X = 0; CPU0 CPU1 rwsem_down_read() for (;;) { set_current_state(TASK_UNINTERRUPTIBLE); X = 1; rwsem_up_write(); rwsem_mark_wake() atomic_long_add(adjustment, &sem->count); smp_store_release(&waiter->task, NULL); if (!waiter.task) break; ... } r = X; Allows 'r == 0'. Reported-by: Will Deacon Signed-off-by: Peter Zijlstra (Intel) Acked-by: Will Deacon Cc: Linus Torvalds Cc: Peter Hurley Cc: Peter Zijlstra Cc: Thomas Gleixner Fixes: 4898e640caf0 ("tty: Add timed, writer-prioritized rw semaphore") Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin

serial: sh-sci: Fix TX DMA buffer flushing and workqueue races

2019-07-31T05:24:46+00:00

[ Upstream commit 8493eab02608b0e82f67b892aa72882e510c31d0 ] When uart_flush_buffer() is called, the .flush_buffer() callback zeroes the tx_dma_len field. This may race with the work queue function handling transmit DMA requests: 1. If the buffer is flushed before the first DMA API call, dmaengine_prep_slave_single() may be called with a zero length, causing the DMA request to never complete, leading to messages like: rcar-dmac e7300000.dma-controller: Channel Address Error happen and, with debug enabled: sh-sci e6e88000.serial: sci_dma_tx_work_fn: ffff800639b55000: 0...0, cookie 126 and DMA timeouts. 2. If the buffer is flushed after the first DMA API call, but before the second, dma_sync_single_for_device() may be called with a zero length, causing the transmit data not to be flushed to RAM, and leading to stale data being output. Fix this by: 1. Letting sci_dma_tx_work_fn() return immediately if the transmit buffer is empty, 2. Extending the critical section to cover all DMA preparational work, so tx_dma_len stays consistent for all of it, 3. Using local copies of circ_buf.head and circ_buf.tail, to make sure they match the actual operation above. Reported-by: Eugeniu Rosca Suggested-by: Yoshihiro Shimoda Signed-off-by: Geert Uytterhoeven Reviewed-by: Eugeniu Rosca Tested-by: Eugeniu Rosca Link: https://lore.kernel.org/r/20190624123540.20629-2-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: sh-sci: Terminate TX DMA during buffer flushing

2019-07-31T05:24:46+00:00

[ Upstream commit 775b7ffd7d6d5db320d99b0a485c51e04dfcf9f1 ] While the .flush_buffer() callback clears sci_port.tx_dma_len since commit 1cf4a7efdc71cab8 ("serial: sh-sci: Fix race condition causing garbage during shutdown"), it does not terminate a transmit DMA operation that may be in progress. Fix this by terminating any pending DMA operations, and resetting the corresponding cookie. Signed-off-by: Geert Uytterhoeven Reviewed-by: Eugeniu Rosca Tested-by: Eugeniu Rosca Link: https://lore.kernel.org/r/20190624123540.20629-3-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: mctrl_gpio: Check if GPIO property exisits before requesting it

2019-07-31T05:24:42+00:00

[ Upstream commit d99482673f950817b30caf3fcdfb31179b050ce1 ] This patch adds a check for the GPIOs property existence, before the GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio support is added (2nd patch in this patch series) on x86 platforms using ACPI. Here Mika's comments from 2016-08-09: " I noticed that with v4.8-rc1 serial console of some of our Broxton systems does not work properly anymore. I'm able to see output but input does not work. I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341 ("tty/serial/8250: use mctrl_gpio helpers"). The reason why it fails is that in ACPI we do not have names for GPIOs (except when _DSD is used) so we use the "idx" to index into _CRS GPIO resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The UART device in Broxton has following (simplified) ACPI description: Device (URT4) { ... Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO0", 0x00, ResourceConsumer) { 0x003A } GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO0", 0x00, ResourceConsumer) { 0x003D } }) In this case it finds the first GPIO (0x003A which happens to be RX pin for that UART), turns it into GPIO which then breaks input for the UART device. This also breaks systems with bluetooth connected to UART (those typically have some GPIOs in their _CRS). Any ideas how to fix this? We cannot just drop the _CRS index lookup fallback because that would break many existing machines out there so maybe we can limit this to only DT enabled machines. Or alternatively probe if the property first exists before trying to acquire the GPIOs (using device_property_present()). " This patch implements the fix suggested by Mika in his statement above. Signed-off-by: Stefan Roese Reviewed-by: Mika Westerberg Reviewed-by: Andy Shevchenko Tested-by: Yegor Yefremov Cc: Mika Westerberg Cc: Andy Shevchenko Cc: Yegor Yefremov Cc: Greg Kroah-Hartman Cc: Giulio Benetti Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

tty: serial_core: Set port active bit in uart_port_activate

2019-07-31T05:24:41+00:00

[ Upstream commit 13b18d35909707571af9539f7731389fbf0feb31 ] A bug was introduced by commit b3b576461864 ("tty: serial_core: convert uart_open to use tty_port_open"). It caused a constant warning printed into the system log regarding the tty and port counter mismatch: [ 21.644197] ttyS ttySx: tty_port_close_start: tty->count = 1 port count = 2 in case if session hangup was detected so the warning is printed starting from the second open-close iteration. Particularly the problem was discovered in situation when there is a serial tty device without hardware back-end being setup. It is considered by the tty-serial subsystems as a hardware problem with session hang up. In this case uart_startup() will return a positive value with TTY_IO_ERROR flag set in corresponding tty_struct instance. The same value will get passed to be returned from the activate() callback and then being returned from tty_port_open(). But since in this case tty_port_block_til_ready() isn't called the TTY_PORT_ACTIVE flag isn't set (while the method had been called before tty_port_open conversion was introduced and the rest of the subsystem code expected the bit being set in this case), which prevents the uart_hangup() method to perform any cleanups including the tty port counter setting to zero. So the next attempt to open/close the tty device will discover the counters mismatch. In order to fix the problem we need to manually set the TTY_PORT_ACTIVE flag in case if uart_startup() returned a positive value. In this case the hang up procedure will perform a full set of cleanup actions including the port ref-counter resetting. Fixes: b3b576461864 "tty: serial_core: convert uart_open to use tty_port_open" Signed-off-by: Serge Semin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: uartps: Use the same dynamic major number for all ports

2019-07-31T05:24:41+00:00

[ Upstream commit ab262666018de6f4e206b021386b93ed0c164316 ] Let kernel to find out major number dynamically for the first device and then reuse it for other instances. This fixes the issue that each uart is registered with a different major number. After the patch: crw------- 1 root root 253, 0 Jun 10 08:31 /dev/ttyPS0 crw--w---- 1 root root 253, 1 Jan 1 1970 /dev/ttyPS1 Fixes: 024ca329bfb9 ("serial: uartps: Register own uart console and driver structures") Signed-off-by: Shubhrajyoti Datta Signed-off-by: Michal Simek Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: imx: fix locking in set_termios()

2019-07-31T05:24:40+00:00

[ Upstream commit 4e828c3e09201512be5ee162393f334321f7cf01 ] imx_uart_set_termios() called imx_uart_rts_active(), or imx_uart_rts_inactive() before taking port->port.lock. As a consequence, sport->port.mctrl that these functions modify could have been changed without holding port->port.lock. Moved locking of port->port.lock above the calls to fix the issue. Signed-off-by: Sergey Organov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

sunhv: Fix device naming inconsistency between sunhv_console and sunhv_reg

2019-07-31T05:24:39+00:00

[ Upstream commit 07a6d63eb1b54b5fb38092780fe618dfe1d96e23 ] In d5a2aa24, the name in struct console sunhv_console was changed from "ttyS" to "ttyHV" while the name in struct uart_ops sunhv_pops remained unchanged. This results in the hypervisor console device to be listed as "ttyHV0" under /proc/consoles while the device node is still named "ttyS0": root@osaka:~# cat /proc/consoles ttyHV0 -W- (EC p ) 4:64 tty0 -WU (E ) 4:1 root@osaka:~# readlink /sys/dev/char/4:64 ../../devices/root/f02836f0/f0285690/tty/ttyS0 root@osaka:~# This means that any userland code which tries to determine the name of the device file of the hypervisor console device can not rely on the information provided by /proc/consoles. In particular, booting current versions of debian- installer inside a SPARC LDOM will fail with the installer unable to determine the console device. After renaming the device in struct uart_ops sunhv_pops to "ttyHV" as well, the inconsistency is fixed and it is possible again to determine the name of the device file of the hypervisor console device by reading the contents of /proc/console: root@osaka:~# cat /proc/consoles ttyHV0 -W- (EC p ) 4:64 tty0 -WU (E ) 4:1 root@osaka:~# readlink /sys/dev/char/4:64 ../../devices/root/f02836f0/f0285690/tty/ttyHV0 root@osaka:~# With this change, debian-installer works correctly when installing inside a SPARC LDOM. Signed-off-by: John Paul Adrian Glaubitz Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

serial: 8250: Fix TX interrupt handling condition

2019-07-31T05:24:38+00:00

[ Upstream commit db1b5bc047b3cadaedab3826bba82c3d9e023c4b ] Interrupt handler checked THRE bit (transmitter holding register empty) in LSR to detect if TX fifo is empty. In case when there is only receive interrupts the TX handling got called because THRE bit in LSR is set when there is no transmission (FIFO empty). TX handling caused TX stop, which in RS-485 half-duplex mode actually resets receiver FIFO. This is not desired during reception because of possible data loss. The fix is to check if THRI is set in IER in addition of the TX fifo status. THRI in IER is set when TX is started and cleared when TX is stopped. This ensures that TX handling is only called when there is really transmission on going and an interrupt for THRE and not when there are only RX interrupts. Signed-off-by: Kimmo Rautkoski Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

tty: serial: msm_serial: avoid system lockup condition

2019-07-31T05:24:38+00:00

[ Upstream commit ba3684f99f1b25d2a30b6956d02d339d7acb9799 ] The function msm_wait_for_xmitr can be taken with interrupts disabled. In order to avoid a potential system lockup - demonstrated under stress testing conditions on SoC QCS404/5 - make sure we wait for a bounded amount of time. Tested on SoC QCS404. Signed-off-by: Jorge Ramirez-Ortiz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin