Re: [PATCH v2 1/9] Input: cap11xx - clean up duplicate log and add probe error logs

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Threaded interrupt handler returns IRQ_HANDLED on I2C failure, potentially causing an interrupt storm.
--

commit f746dddeb8894305a4dab485d320b84f53191dc0
Author: Jun Yan <jerrysteve1101@gmail.com>

Input: cap11xx - clean up duplicate log and add probe error logs

This commit removes a duplicated device detection log entry to clean up
dmesg output. It also adds missing error logs using dev_err_probe()
when I2C communication fails during the driver's probe sequence.

> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
> index 2447c1ae21661..485d8ba977235 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c

[ ... ]

> @@ -531,11 +531,8 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
>  	}
>  
>  	error = regmap_read(priv->regmap, CAP11XX_REG_REVISION, &rev);
> -	if (error < 0)
> -		return error;
> -
> -	dev_info(dev, "CAP11XX detected, model %s, revision 0x%02x\n",
> -			 id->name, rev);
> +	if (error)
> +		return dev_err_probe(dev, error, "Failed to read revision\n");
>  
>  	priv->model = cap;

[Severity: High]
This isn't a bug introduced by this patch, but while looking at I2C failure
handling in this driver, I noticed an issue in cap11xx_thread_func().

If I2C communication fails during the interrupt handler, the code jumps to
the out label:

drivers/input/keyboard/cap11xx.c:cap11xx_thread_func() {
	...
	ret = regmap_update_bits(priv->regmap, CAP11XX_REG_MAIN_CONTROL, 1, 0);
	if (ret < 0)
		goto out;
	...
out:
	return IRQ_HANDLED;
}

Because it unconditionally returns IRQ_HANDLED without deasserting the
hardware interrupt, the level-triggered interrupt line remains active. This
causes the interrupt controller to unmask the IRQ and immediately trigger it
again, creating an infinite loop (interrupt storm) that can lock up the CPU.

Should the handler return IRQ_NONE upon I2C failure so the kernel's spurious
interrupt detector can eventually disable the broken IRQ?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260612072237.1177304-1-jerrysteve1101@gmail.com?part=1