Re: [PATCH v3 02/10] Input: cap11xx - remove unused register macros

[sashiko-bot@kernel.org]

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

New issues:
- [Medium] Removing sensor delta registers from the volatile register list causes regmap to incorrectly cache their values, breaking debugfs observability.

Pre-existing issues:
- [High] The driver requests its IRQ after registering the input device, creating a race condition where an unhandled interrupt can permanently disable the device.
--

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

Input: cap11xx - remove unused register macros
    
Remove unused register address macros and unused definitions in
the cap11xx_reg_defaults array and cap11xx_volatile_reg. This cleanup
reduces code clutter and makes the driver easier to maintain.

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

[ ... ]

> @@ -149,12 +97,6 @@ static bool cap11xx_volatile_reg(struct device *dev, unsigned int reg)
>  	switch (reg) {
>  	case CAP11XX_REG_MAIN_CONTROL:
>  	case CAP11XX_REG_SENSOR_INPUT:
> -	case CAP11XX_REG_SENOR_DELTA(0):
> -	case CAP11XX_REG_SENOR_DELTA(1):
> -	case CAP11XX_REG_SENOR_DELTA(2):
> -	case CAP11XX_REG_SENOR_DELTA(3):
> -	case CAP11XX_REG_SENOR_DELTA(4):
> -	case CAP11XX_REG_SENOR_DELTA(5):

[Severity: Medium]
Does removing the sensor delta registers from the volatile list cause a
regression for observability via the regmap debugfs interface?

These registers contain real-time capacitance delta hardware values that are
continuously updated by the device. Treating them as non-volatile causes
regmap to cache them on the first read, resulting in stale values for any
subsequent reads by tuning tools or developers.

>  		return true;
>  	}
>  

[Severity: High]
This isn't a bug introduced by this patch, but I noticed a pre-existing probe
ordering flaw in cap11xx_i2c_probe():

	error = input_register_device(priv->idev);
	if (error)
		return error;

	error = devm_request_threaded_irq(dev, i2c_client->irq,
					  NULL, cap11xx_thread_func,
					  IRQF_ONESHOT, dev_name(dev), priv);

Could this sequence lead to the interrupt being permanently disabled?

Since input_register_device() exposes the device to userspace, a daemon
can immediately open the device, waking the sensor from deep sleep.

If the sensor generates a hardware interrupt before
devm_request_threaded_irq() completes, the generic IRQ core will receive an
interrupt with no registered handler.

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