Uart_write_wakeup() will already be called as a part of
lpuart*_transmit_buffer() call, so there doesn't seem to be a reason
to call it again right after.
It also appears that second uart_write_wakeup() might potentially
cause unwanted write wakeup when transmitting an x_char. See commit
5e42e9a30cda ("serial: imx: Fix x_char handling and tx flow control")
where this problem was fixed in a very similarly structured i.MX UART
driver.
Signed-off-by: Andrey Smirnov <andrew.smirnov@xxxxxxxxx>
Cc: Stefan Agner <stefan@xxxxxxxx>
Cc: Bhuvanchandra DV <bhuvanchandra.dv@xxxxxxxxxxx>
Cc: Chris Healy <cphealy@xxxxxxxxx>
Cc: Cory Tusar <cory.tusar@xxxxxxxx>
Cc: Lucas Stach <l.stach@xxxxxxxxxxxxxx>
Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Cc: Jiri Slaby <jslaby@xxxxxxxx>
Cc: linux-imx@xxxxxxx
Cc: linux-serial@xxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx
---
drivers/tty/serial/fsl_lpuart.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index b600f591c8c2..840dcbb27e5a 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -797,9 +797,6 @@ static void lpuart_txint(struct lpuart_port *sport)
else
lpuart_transmit_buffer(sport);
- if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
- uart_write_wakeup(&sport->port);
-
out:
spin_unlock_irqrestore(&sport->port.lock, flags);
}
--
2.21.0
