linux/drivers/tty/serial/sh-sci.c, branch v5.3

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

2019-07-03T17:31:30Z

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

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

2019-07-03T17:31:30Z

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

serial: sh-sci: disable DMA for uart_console

2019-05-21T10:18:17Z

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

serial: sh-sci: Fix HSCIF RX sampling point adjustment

2019-04-16T13:24:38Z

The calculation of the sampling point has min() and max() exchanged. Fix this by using the clamp() helper instead. Fixes: 63ba1e00f178a448 ("serial: sh-sci: Support for HSCIF RX sampling point adjustment") Signed-off-by: Geert Uytterhoeven Reviewed-by: Ulrich Hecht Reviewed-by: Wolfram Sang Acked-by: Dirk Behme Cc: stable Reviewed-by: Simon Horman Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Fix HSCIF RX sampling point calculation

2019-04-16T13:24:38Z

There are several issues with the formula used for calculating the deviation from the intended rate: 1. While min_err and last_stop are signed, srr and baud are unsigned. Hence the signed values are promoted to unsigned, which will lead to a bogus value of deviation if min_err is negative, 2. Srr is the register field value, which is one less than the actual sampling rate factor, 3. The divisions do not use rounding. Fix this by casting unsigned variables to int, adding one to srr, and using a single DIV_ROUND_CLOSEST(). Fixes: 63ba1e00f178a448 ("serial: sh-sci: Support for HSCIF RX sampling point adjustment") Signed-off-by: Geert Uytterhoeven Reviewed-by: Mukesh Ojha Cc: stable Reviewed-by: Ulrich Hecht Signed-off-by: Greg Kroah-Hartman

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

2019-03-19T14:37:44Z

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

Merge 5.0-rc6 into tty-next

2019-02-11T08:26:45Z

We need the tty fixes in here for other patches to be based on. Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Do not free irqs that have already been freed

2019-01-30T08:35:46Z

Since IRQs might be muxed on some parts, we need to pay attention when we are freeing them. Otherwise we get the ugly WARNING "Trying to free already-free IRQ 20". Fixes: 628c534ae735 ("serial: sh-sci: Improve support for separate TEI and DRI interrupts") Cc: stable Signed-off-by: Chris Brandt Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Make RX/TX DMA function names consistent

2019-01-08T15:56:52Z

Most RX/TX-specific DMA functions are prefixed with "sci_dma_[rt]x_". Rename the exceptions to increase consistency. Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Fix fallback to PIO in sci_dma_rx_complete()

2019-01-08T15:56:52Z

When submitting a DMA request fails in sci_dma_rx_complete(), the driver tries to fall back to PIO, but that does not work: no more data will be received, or the kernel will even crash. Fix this similar as in (but not identical to) sci_submit_rx(): - On SCIF, PIO cannot take over if any DMA transactions are pending, hence they must be terminated first. - All active cookies must be invalidated, else rx_timer_fn() may trigger a NULL pointer dereference. - Restarting the port is not needed, as it is already running, but serial port interrupts must be directed back from the DMA engine to the CPU. Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Greg Kroah-Hartman