Re: [PATCH 5/7] Input: gscps2 - return IRQ_NONE when interrupt is not handled

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unbounded hardware status polling loop can cause a hard CPU lockup
--

commit 9f561e93b317449afad0b8c42cee86d0e78216d9
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input: gscps2 - return IRQ_NONE when interrupt is not handled

This commit modifies the GSC PS/2 driver to track whether any bytes were
handled during an interrupt and returns the appropriate IRQ status. This
prevents masking unhandled interrupts on a shared line.

> diff --git a/drivers/input/serio/gscps2.c b/drivers/input/serio/gscps2.c
> index 36c25db9ff7f6..907fb1537595c 100644
> --- a/drivers/input/serio/gscps2.c
> +++ b/drivers/input/serio/gscps2.c
[ ... ]
> @@ -247,11 +248,14 @@ static void gscps2_read_data(struct gscps2port *ps2port)
>  		if (!(status & GSC_STAT_RBNE))
>  			break;
>  
> +		read_any = true;
>  		ps2port->buffer[ps2port->append].str = status;
>  		ps2port->buffer[ps2port->append].data =
>  				gscps2_readb_input(ps2port->addr);
>  		ps2port->append = (ps2port->append + 1) & BUFFER_SIZE;
>  	} while (true);

[Severity: High]
This is a pre-existing issue, but could this unbounded hardware polling loop
cause a hard CPU lockup?

If the PS/2 controller malfunctions and fails to clear the GSC_STAT_RBNE bit
after a read, this loop will never exit. Since gscps2_interrupt runs with
local interrupts disabled, this would freeze the system.

Could we add a bounded iteration guard or retry limit here?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260830-gscps2-v1-0-c733d4cae7f9@gmail.com?part=5