Re: [PATCH 1/1] serial: 8250: Fix TX interrupt handling condition in 8250_fsl.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 21, 2020 at 10:43:13AM +0200, drolevar@xxxxxxxxx wrote:
> From: Andrij Abyzov <aabyzov@xxxxxxx>
> 
> This is a port of the commit
> db1b5bc047b3cadaedab3826bba82c3d9e023c4b ("Fix TX interrupt handling condition")
> to the FSL-specifific interrupt handling routine.

See the kernel documentation file "submitting patches" for how to
reference commits within changelogs.  This paragraph should look
something like:

	This is the port of the commit db1b5bc047b3 ("serial: 8250: Fix TX
	interrupt handling condition") to the 8250_fsl irq handling logic.

Right?

> Interrupt handler checked THRE bit (transmitter holding register
> empty) in LSR to detect if TX fifo is empty.
> In case when there is only receive interrupts the TX handling
> got called because THRE bit in LSR is set when there is no
> transmission (FIFO empty). TX handling caused TX stop, which in
> RS-485 half-duplex mode actually resets receiver FIFO. This is not
> desired during reception because of possible data loss.
> 
> The fix is to check if THRI is set in IER in addition of the TX
> fifo status. THRI in IER is set when TX is started and cleared
> when TX is stopped.
> This ensures that TX handling is only called when there is really
> transmission on going and an interrupt for THRE and not when there
> are only RX interrupts.
> 
> Signed-off-by: Andrij Abyzov <aabyzov@xxxxxxx>
> ---
>  drivers/tty/serial/8250/8250_fsl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_fsl.c b/drivers/tty/serial/8250/8250_fsl.c
> index 0d0c80905c58..ceac6cfce4c7 100644
> --- a/drivers/tty/serial/8250/8250_fsl.c
> +++ b/drivers/tty/serial/8250/8250_fsl.c
> @@ -71,7 +71,7 @@ int fsl8250_handle_irq(struct uart_port *port)
>  
>  	serial8250_modem_status(up);
>  
> -	if (lsr & UART_LSR_THRE)
> +	if ((lsr & UART_LSR_THRE) && (up->ier & UART_IER_THRI))
>  		serial8250_tx_chars(up);

Does this fix up a bug that has always been there, or was caused by a
specific kernel change?  If a specific one, please list that on the
Fixes: line.

Can you fix this up and resend?

thanks,

greg k-h



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux