kernel/linux.git/drivers/tty/serial/sh-sci.c, branch v4.14.217

serial: sh-sci: Make sure status register SCxSR is read in correct sequence

2020-05-02T15:24:38+00:00

commit 3dc4db3662366306e54ddcbda4804acb1258e4ba upstream. For SCIF and HSCIF interfaces the SCxSR register holds the status of data that is to be read next from SCxRDR register, But where as for SCIFA and SCIFB interfaces SCxSR register holds status of data that is previously read from SCxRDR register. This patch makes sure the status register is read depending on the port types so that errors are caught accordingly. Cc: Signed-off-by: Kazuhiro Fujita Signed-off-by: Hao Bui Signed-off-by: KAZUMI HARADA Signed-off-by: Lad Prabhakar Tested-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/1585333048-31828-1-git-send-email-kazuhiro.fujita.jg@renesas.com Signed-off-by: Greg Kroah-Hartman

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

2019-07-31T05:28:54+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:28:54+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: sh-sci: disable DMA for uart_console

2019-06-09T07:18:18+00:00

commit 099506cbbc79c0bd52b19cb6b930f256dabc3950 upstream. As noted in commit 84b40e3b57ee ("serial: 8250: omap: Disable DMA for console UART"), UART console lines use low-level PIO only access functions which will conflict with use of the line when DMA is enabled, e.g. when the console line is also used for systemd messages. So disable DMA support for UART console lines. Reported-by: Michael Rodin Link: https://patchwork.kernel.org/patch/10929511/ Tested-by: Eugeniu Rosca Reviewed-by: Simon Horman Reviewed-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Cc: stable@vger.kernel.org Signed-off-by: George G. Davis Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Fix setting SCSCR_TIE while transferring data

2019-04-03T04:25:18+00:00

commit 93bcefd4c6bad4c69dbc4edcd3fbf774b24d930d upstream. We disable transmission interrupt (clear SCSCR_TIE) after all data has been transmitted (if uart_circ_empty(xmit)). While transmitting, if the data is still in the tty buffer, re-enable the SCSCR_TIE bit, which was done at sci_start_tx(). This is unnecessary processing, wasting CPU operation if the data transmission length is large. And further, transmit end, FIFO empty bits disabling have also been performed in the step above. Signed-off-by: Hoan Nguyen An Cc: stable Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Stop RX FIFO timer during port shutdown

2018-10-04T00:00:46+00:00

[ Upstream commit c5a9262fa8bfed0dddc7466ef10fcd292e2af61b ] The RX FIFO timer may be armed when the port is shut down, hence the timer function may still be called afterwards. Fix this race condition by deleting the timer during port shutdown. Fixes: 039403765e5da3c6 ("serial: sh-sci: SCIFA/B RX FIFO software timeout") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Use spin_{try}lock_irqsave instead of open coding version

2018-07-03T09:24:47+00:00

commit 8afb1d2c12163f77777f84616a8e9444d0050ebe upstream. Commit 40f70c03e33a ("serial: sh-sci: add locking to console write function to avoid SMP lockup") copied the strategy to avoid locking problems in conjuncture with the console from the UART8250 driver. Instead using directly spin_{try}lock_irqsave(), local_irq_save() followed by spin_{try}lock() was used. While this is correct on mainline, for -rt it is a problem. spin_{try}lock() will check if it is running in a valid context. Since the local_irq_save() has already been executed, the context has changed and spin_{try}lock() will complain. The reason why spin_{try}lock() complains is that on -rt the spin locks are turned into mutexes and therefore can sleep. Sleeping with interrupts disabled is not valid. BUG: sleeping function called from invalid context at /home/wagi/work/rt/v4.4-cip-rt/kernel/locking/rtmutex.c:995 in_atomic(): 0, irqs_disabled(): 128, pid: 778, name: irq/76-eth0 CPU: 0 PID: 778 Comm: irq/76-eth0 Not tainted 4.4.126-test-cip22-rt14-00403-gcd03665c8318 #12 Hardware name: Generic RZ/G1 (Flattened Device Tree) Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r7:c06b01f0 r6:60010193 r5:00000000 r4:c06b01f0 [] (show_stack) from [] (dump_stack+0x78/0x94) [] (dump_stack) from [] (___might_sleep+0x134/0x194) r7:60010113 r6:c06d3559 r5:00000000 r4:ffffe000 [] (___might_sleep) from [] (rt_spin_lock+0x20/0x74) r5:c06f4d60 r4:c06f4d60 [] (rt_spin_lock) from [] (serial_console_write+0x100/0x118) r5:c06f4d60 r4:c06f4d60 [] (serial_console_write) from [] (call_console_drivers.constprop.15+0x10c/0x124) r10:c06d2894 r9:c04e18b0 r8:00000028 r7:00000000 r6:c06d3559 r5:c06d2798 r4:c06b9914 r3:c02576e4 [] (call_console_drivers.constprop.15) from [] (console_unlock+0x32c/0x430) r10:c06d30d8 r9:00000028 r8:c06dd518 r7:00000005 r6:00000000 r5:c06d2798 r4:c06d2798 r3:00000028 [] (console_unlock) from [] (vprintk_emit+0x394/0x4f0) r10:c06d2798 r9:c06d30ee r8:00000006 r7:00000005 r6:c06a78fc r5:00000027 r4:00000003 [] (vprintk_emit) from [] (vprintk+0x28/0x30) r10:c060bd46 r9:00001000 r8:c06b9a90 r7:c06b9a90 r6:c06b994c r5:c06b9a3c r4:c0062fa8 [] (vprintk) from [] (vprintk_default+0x10/0x14) [] (vprintk_default) from [] (printk+0x78/0x84) [] (printk) from [] (credit_entropy_bits+0x17c/0x2cc) r3:00000001 r2:decade60 r1:c061a5ee r0:c061a523 r4:00000006 [] (credit_entropy_bits) from [] (add_interrupt_randomness+0x160/0x178) r10:466e7196 r9:1f536000 r8:fffeef74 r7:00000000 r6:c06b9a60 r5:c06b9a3c r4:dfbcf680 [] (add_interrupt_randomness) from [] (irq_thread+0x1e8/0x248) r10:c006537c r9:c06cdf21 r8:c0064fcc r7:df791c24 r6:df791c00 r5:ffffe000 r4:df525180 [] (irq_thread) from [] (kthread+0x108/0x11c) r10:00000000 r9:00000000 r8:c0065184 r7:df791c00 r6:00000000 r5:df791d00 r4:decac000 [] (kthread) from [] (ret_from_fork+0x14/0x3c) r8:00000000 r7:00000000 r6:00000000 r5:c003fa9c r4:df791d00 Cc: Sebastian Andrzej Siewior Signed-off-by: Daniel Wagner Reviewed-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Stop using printk format %pCr

2018-06-16T07:45:16+00:00

commit d63c16f8e1ab761775275adcf54f4bef7c330295 upstream. Printk format "%pCr" will be removed soon, as clk_get_rate() must not be called in atomic context. Replace it by open-coding the operation. This is safe here, as the code runs in task context. Link: http://lkml.kernel.org/r/1527845302-12159-4-git-send-email-geert+renesas@glider.be To: Jia-Ju Bai To: Jonathan Corbet To: Michael Turquette To: Stephen Boyd To: Zhang Rui To: Eduardo Valentin To: Eric Anholt To: Stefan Wahren To: Greg Kroah-Hartman Cc: Sergey Senozhatsky Cc: Petr Mladek Cc: Linus Torvalds Cc: Steven Rostedt Cc: linux-doc@vger.kernel.org Cc: linux-clk@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: linux-serial@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Geert Uytterhoeven Cc: stable@vger.kernel.org # 4.5+ Signed-off-by: Geert Uytterhoeven Signed-off-by: Petr Mladek Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Fix out-of-bounds access through DT alias

2018-05-25T14:17:58+00:00

[ Upstream commit 090fa4b0dccfa3d04e1c5ab0fe4eba16e6713895 ] The sci_ports[] array is indexed using a value derived from the "serialN" alias in DT, which may lead to an out-of-bounds access. Fix this by adding a range check. Note that the array size is defined by a Kconfig symbol (CONFIG_SERIAL_SH_SCI_NR_UARTS), so this can even be triggered using a legitimate DTB. Fixes: 97ed9790c514066b ("serial: sh-sci: Remove unused platform data capabilities field") Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: prevent lockup on full TTY buffers

2018-03-19T07:42:45+00:00

commit 7842055bfce4bf0170d0f61df8b2add8399697be upstream. When the TTY buffers fill up to the configured maximum, a system lockup occurs: [ 598.820128] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 598.825796] 0-...!: (1 GPs behind) idle=5a6/2/0 softirq=1974/1974 fqs=1 [ 598.832577] (detected by 3, t=62517 jiffies, g=296, c=295, q=126) [ 598.838755] Task dump for CPU 0: [ 598.841977] swapper/0 R running task 0 0 0 0x00000022 [ 598.849023] Call trace: [ 598.851476] __switch_to+0x98/0xb0 [ 598.854870] (null) This can be prevented by doing a dummy read of the RX data register. This issue affects both HSCIF and SCIF ports. Reported for R-Car H3 ES2.0; reproduced and fixed on H3 ES1.1. Probably affects other R-Car platforms as well. Reported-by: Yoshihiro Shimoda Signed-off-by: Ulrich Hecht Reviewed-by: Geert Uytterhoeven Cc: stable Tested-by: Nguyen Viet Dung Signed-off-by: Greg Kroah-Hartman