Re: [PATCH] Input: synaptics-rmi4 - add support for reset gpios

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing reset GPIO assertion before disabling regulators on driver unbind and probe error paths leads to potential backpowering.
--

commit 11e1dedc5b986fa6ff95c5549b898574a80bff23
Author: Roman Vivchar <rva333@protonmail.com>

Input: synaptics-rmi4 - add support for reset gpios

In some cases, the touchscreen is wired to the always-on regulator, so
resetting is required for proper I2C communication. Add reset support to
the rmi_i2c driver.

> diff --git a/drivers/input/rmi4/rmi_i2c.c b/drivers/input/rmi4/rmi_i2c.c
> index e11d0acb9b96d..da560988f44a1 100644
> --- a/drivers/input/rmi4/rmi_i2c.c
> +++ b/drivers/input/rmi4/rmi_i2c.c
[ ... ]
> @@ -235,6 +247,11 @@ static int rmi_i2c_probe(struct i2c_client *client)
>  	if (error < 0)
>  		return error;
>  
> +	rmi_i2c->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
> +						      GPIOD_OUT_HIGH);
> +	if (IS_ERR(rmi_i2c->reset_gpio))
> +		return PTR_ERR(rmi_i2c->reset_gpio);
> +
>  	error = regulator_bulk_enable(ARRAY_SIZE(rmi_i2c->supplies),
>  				       rmi_i2c->supplies);
>  	if (error < 0)

[Severity: High]
If a probe error occurs later in rmi_i2c_probe() (for example, when calling
rmi_register_transport_device()), or if the driver is unbound, devres will
run rmi_i2c_regulator_bulk_disable() to disable the regulators.

Should the reset GPIO be asserted before disabling the regulators in the
devres cleanup paths? 

Unlike the suspend callbacks which do assert the GPIO, the devres cleanup
does not. This appears to leave the reset GPIO driven while the chip is
unpowered, which could lead to backpowering the device.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912-rmi4-reset-v1-1-4a3fc8856830@protonmail.com?part=1