Re: [PATCH v2] Input: s6sy761 - fix resume ordering and restore sensing

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] input: permanent IRQ disable on s6sy761_power_on() failure
--

commit e5e3e44a0960351c54b4dc02894567b7b504952c
Author: David Heidelberg <david@ixit.cz>

Input: s6sy761 - fix resume ordering and restore sensing

This commit alters the resume ordering to power on the controller before
unmasking the interrupt, addressing an issue where the boot-complete
event was consumed prematurely. It also ensures SENSE_ON is re-sent upon
resume if the input device is already open.

> diff --git a/drivers/input/touchscreen/s6sy761.c b/drivers/input/touchscreen/s6sy761.c
> index 0f24a9b730635..899c179fb2d31 100644
> --- a/drivers/input/touchscreen/s6sy761.c
> +++ b/drivers/input/touchscreen/s6sy761.c
> @@ -500,10 +500,22 @@ static int s6sy761_suspend(struct device *dev)
>  static int s6sy761_resume(struct device *dev)
>  {
>  	struct s6sy761_data *sdata = dev_get_drvdata(dev);
> +	int err;
> +
> +	err = s6sy761_power_on(sdata);
> +	if (err)
> +		return err;

[Severity: Medium]
Will this early return permanently disable the interrupt if power on fails?

If s6sy761_power_on() fails (for example, due to a transient I2C error
during resume), this early return skips enable_irq(). However, the PM core
will still clear the suspended state despite the error.

On the next system suspend cycle, s6sy761_suspend() will run again and call
disable_irq(), which unconditionally increments the IRQ disable depth to 2.
A subsequent successful resume would then call enable_irq() only once,
reducing the depth back to 1, which leaves the IRQ permanently disabled.

Should the error path balance the IRQ state to avoid losing touchscreen
functionality after a transient failure?

>  
>  	enable_irq(sdata->client->irq);
>  

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926-s6sy761-suspend-v2-1-8f00a96ee6e8@ixit.cz?part=1