Commit f77232dab25b ("tty: serial: msm: drop uart_port->lock before
calling tty_flip_buffer_push()") claimed to address a locking
issue but only provided a dubious lockdep splat from an unrelated
driver, which in the end turned out to be due a broken local change
carried by the author.
Unfortunately these patches were merged before the issue had been
analysed properly so the commit messages makes no sense whatsoever.
The real issue was first seen on RT which at the time effectively always
set the low_latency flag for all serial drivers by patching
tty_flip_buffer_push(). This in turn revealed that many drivers did not
handle the infamous low_latency behaviour which meant that data was
pushed immediately to the line discipline instead of being deferred to a
work queue.
Since commit a9c3f68f3cd8 ("tty: Fix low_latency BUG"),
tty_flip_buffer_push() always schedules a work item to push data to the
line discipline and there's no need to keep any low_latency hacks
around.
Link: https://lore.kernel.org/linux-serial/cover.1376923198.git.viresh.kumar@xxxxxxxxxx/
Cc: Andy Gross <agross@xxxxxxxxxx>
Cc: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>
Signed-off-by: Johan Hovold <johan@xxxxxxxxxx>
---
drivers/tty/serial/msm_serial.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index 770c182e2208..fcef7a961430 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -757,9 +757,7 @@ static void msm_handle_rx_dm(struct uart_port *port, unsigned int misr)
count -= r_count;
}
- spin_unlock(&port->lock);
tty_flip_buffer_push(tport);
- spin_lock(&port->lock);
if (misr & (UART_IMR_RXSTALE))
msm_write(port, UART_CR_CMD_RESET_STALE_INT, UART_CR);
@@ -819,9 +817,7 @@ static void msm_handle_rx(struct uart_port *port)
tty_insert_flip_char(tport, c, flag);
}
- spin_unlock(&port->lock);
tty_flip_buffer_push(tport);
- spin_lock(&port->lock);
}
static void msm_handle_tx_pio(struct uart_port *port, unsigned int tx_count)
--
2.26.3
