linux-kernel - Re: [PATCH] serial: liteuart: polling all interrupts in the IRQ process

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <vxnamwloznpdjvn4ars4wfx5jnixcybvv62vpvipr5z2lzod4p@zxx4xiyru2yd>
Date: Sat, 30 Aug 2025 17:34:24 +0800
From: Inochi Amaoto <inochiama@...il.com>
To: Karol Gugala <kgugala@...micro.com>, 
	Mateusz Holenko <mholenko@...micro.com>, Gabriel Somlo <gsomlo@...il.com>, Joel Stanley <joel@....id.au>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby <jirislaby@...nel.org>
Cc: Inochi Amaoto <inochiama@...il.com>, linux-kernel@...r.kernel.org, 
	linux-serial@...r.kernel.org, Yixun Lan <dlan@...too.org>, Longbin Li <looong.bin@...il.com>
Subject: Re: [PATCH] serial: liteuart: polling all interrupts in the IRQ
 process

On Tue, Aug 26, 2025 at 04:14:44PM +0800, Inochi Amaoto wrote:
> When using liteuart with aplic and imsic, the new interrupt will lost
> if the interrupt handler can not handle all the data. This is simply
> because the interrupt line will never be low, and the aplic will not
> send the interrupt to imsic again.
> 
> Handle all data in the IRQ handler until no data incoming.
> 
> Signed-off-by: Inochi Amaoto <inochiama@...il.com>
> ---
>  drivers/tty/serial/liteuart.c | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/tty/serial/liteuart.c b/drivers/tty/serial/liteuart.c
> index 6429e8f11f36..436e8f06fb75 100644
> --- a/drivers/tty/serial/liteuart.c
> +++ b/drivers/tty/serial/liteuart.c
> @@ -140,11 +140,17 @@ static irqreturn_t liteuart_interrupt(int irq, void *data)
>  	 * irq[save|restore] spin_lock variants to cover all possibilities
>  	 */
>  	uart_port_lock_irqsave(port, &flags);
> -	isr = litex_read8(port->membase + OFF_EV_PENDING) & uart->irq_reg;
> -	if (isr & EV_RX)
> -		liteuart_rx_chars(port);
> -	if (isr & EV_TX)
> -		liteuart_tx_chars(port);
> +
> +	isr = litex_read8(port->membase + OFF_EV_PENDING);
> +
> +	while (isr & uart->irq_reg) {
> +		if (isr & EV_RX)
> +			liteuart_rx_chars(port);
> +		if (isr & EV_TX)
> +			liteuart_tx_chars(port);
> +		isr = litex_read8(port->membase + OFF_EV_PENDING);
> +	}
> +
>  	uart_port_unlock_irqrestore(port, flags);
>  
>  	return IRQ_RETVAL(isr);
> -- 
> 2.51.0
> 

Just ignore this patch. The problem is caused by our incorrect
hardware implementation. And everything works fine as the hardware
is fixed.

Regards
Inochi