kernel/linux.git/drivers/tty/serial/serial-tegra.c, branch linux-4.4.y

serial: tegra: Add helper function for handling RX buffer

2015-10-18T04:07:57+00:00

In the tegra UART driver there are three places where the RX DMA buffer is handled and pushed up to the tty layer. In all three instances the same functions are called and so instead of duplicating the code in three places, move this code to a new helper function and use this new function. Signed-off-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

serial: tegra: Remove redundant code and check in tegra_uart_stop_rx()

2015-10-18T04:07:57+00:00

The serial-tegra driver always uses DMA and hence the driver always allocates DMA channels. Therefore, the test to see if the RX DMA channel is initialised in tegra_uart_stop_rx() is unnecessary and so remove the test and the code that corresponds to the case where the RX DMA channel is not initialised. Please note that the call to tegra_uart_stop_rx() should always be before the call to tegra_uart_shutdown() which will uninitialise the RX DMA channel. Signed-off-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

serial: tegra: Remove unnecessary return statements

2015-10-18T04:07:57+00:00

Some functions in the serial-tegra driver have unnecessary return statements at the end of a void function and so remove them. Signed-off-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

serial: tegra: Handle another RX race condition

2015-10-18T04:07:57+00:00

Commit 853a699739fe ("serial: tegra: handle race condition on uart rx side") attempted to fix a race condition between the RX end of transmission interrupt and RX DMA completion callback. Despite this fix there is still another case where these two paths can race and result in duplicated data. The race condition is as follows: 1. DMA completion interrupt occurs and schedules tasklet to call DMA callback. 2. DMA callback for the UART driver starts to execute. This will copy the data from the DMA buffer and restart the DMA. This is done under uart port spinlock. 3. During the callback, UART interrupt is raised for end of receive. The UART ISR runs and waits to acquire port spinlock held by the DMA callback. 4. DMA callback gives up spinlock after copying the data, but before restarting DMA. 5. UART ISR acquires the spin lock and reads the same DMA buffer because DMA has not been restarted yet. The release of the spinlock during the DMA callback was introduced by commit 9b88748b362c ("tty: serial: tegra: drop uart_port->lock before calling tty_flip_buffer_push()") to fix a spinlock lock-up issue when calling tty_flip_buffer_push(). However, since then commit a9c3f68f3cd8 ("tty: Fix low_latency BUG") migrated tty_flip_buffer_push() to always use a workqueue, allowing tty_flip_buffer_push() to be called from within atomic sections. Therefore, we can remove the unlocking of the spinlock from the DMA callback and UART ISR and this will ensure that the race condition no longer occurs. Reported-by: Christopher Freeman Signed-off-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

serial: tegra: Fix memory leak on DMA setup failure

2015-05-24T19:53:44+00:00

If the call to dmaengine_slave_config() fails, then the DMA buffer will not be freed/unmapped. Fix this by moving the code that stores the address of the buffer in the tegra_uart_port structure to before the call to dmaengine_slave_config(). Reported-by: Alexandre Courbot Signed-off-by: Jon Hunter Reviewed-by: Alexandre Courbot Signed-off-by: Greg Kroah-Hartman

serial: tegra: Correct error handling on DMA setup

2015-05-10T17:12:19+00:00

Function tegra_uart_dma_channel_allocate() does not check that dma_map_single() mapped the DMA buffer correctly. Add a check for this and appropriate error handling. Furthermore, if dmaengine_slave_config() (called by tegra_uart_dma_channel_allocate()) fails, then memory allocated/mapped is not freed/unmapped. Therefore, call tegra_uart_dma_channel_free() instead of just dma_release_channel() if dmaengine_slave_config() fails. Signed-off-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

serial: tegra: Correct shutdown of UARTs

2015-05-10T17:12:19+00:00

There are two issues in the shutdown path of the UARTs which are: 1. The function tegra_uart_shutdown() calls tegra_uart_flush_buffer() to stop DMA TX transfers. However, tegra_uart_flush_buffer() is called after the DMA channels have already been freed and so actually does nothing. 2. The function that frees the DMA channels (tegra_uart_dma_channel_free()), unmaps the dma buffer before freeing the DMA channel and does not ensure the DMA has been stopped. Resolve this by fixing the code in tegra_uart_dma_channel_free() to ensure the DMA is stopped, free the DMA channel and then unmap the DMA buffer. Finally, remove the unnecessary call to tegra_uart_flush_buffer(). Signed-off-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

serial: tegra: Fix cookie used by TX channel

2015-05-10T17:12:19+00:00

The DMA cookie for the RX channel is being used by the TX channel. Therefore, fix driver to use the correct DMA cookie for the TX channel. Signed-off-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

serial: tegra: Use unsigned types for RX and TX byte counts

2015-05-10T17:12:19+00:00

The function tty_insert_flip_string() takes an argument "size" which is of type size_t. This is an unsigned type. Update the count, rx_bytes_requested and tx_bytes_requested in the tegra serial driver to be unsigned integers so that an unsigned type is passed to tty_insert_flip_string(). Signed-off-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

serial: tegra: handle race condition on uart rx side

2015-05-10T17:12:19+00:00

The tegra serial driver has two paths through which receive data is copied up to the tty layer. These are: 1. DMA completion callback 2. UART RX interrupt A UART RX interrupt occurs for either RX_TIMEOUT (data has been sitting in the Rx FIFO for more than 4 character times without being read because there is not enough data to reach the trigger level), End of Receive Data event (receiver detects that data stops coming in for more than 4 character times) or a receive error. In the RX interrupt path, the following happens ... - All RX DMA transfers are stopped - Any data in the DMA buffer and RX FIFO are copied up to the tty layer. - DMA is restarted/primed for the RX path In the DMA completion callback, the DMA buffer is copied up to the tty layer but there is no check to see if the RX interrupt could have occurred between the DMA interrupt firing the the DMA callback running. Hence, if a RX interrupt was to occur shortly after the DMA completion interrupt, it is possible that the RX interrupt path has already copied the DMA buffer before the DMA callback has been called. Therefore, when the DMA callback is called, if the DMA is already in-progress, then this indicates that the UART RX interrupt has already occurred and there is nothing to do in the DMA callback. This race condition can cause duplicated data to be received. Signed-off-by: Shardar Shariff Md [jonathanh@nvidia.com: Moved async_tx_ack() call to after check to see if DMA has completed because if the DMA is in progress we do not need to ACK yet. Changed the print from dev_info to dev_debug. Updated changelog to add more commentary on the race condition based upon feedback from author.] Signed-off-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman