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.smir...@gmail.com>
Cc: Stefan Agner <ste...@agner.ch>
Cc: Bhuvanchandra DV <bhuvanchandra...@toradex.com>
Cc: Chris Healy <cphe...@gmail.com>
Cc: Cory Tusar <cory.tu...@zii.aero>
Cc: Lucas Stach <l.st...@pengutronix.de>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Jiri Slaby <jsl...@suse.com>
Cc: linux-...@nxp.com
Cc: linux-ser...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
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
