Re: [PATCH v3 2/2] regulator: rpi-panel-v2: Add vcc-supply support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] regulator: leaked enable count on vcc regulator during probe failure and unbind
--

commit db1c448e80eee7e671cad78e558097db3e8ec366
Author: Shashank Maurya <shashank.maurya@oss.qualcomm.com>

regulator: rpi-panel-v2: Add vcc-supply support

The Raspberry Pi 7" touchscreen panel V2 MCU is powered from an external
power rail which has to be enabled before any I2C register access is
attempted. This commit uses devm_regulator_get() to obtain the vcc supply
and enable it at the start of probe.

> diff --git a/drivers/regulator/rpi-panel-v2-regulator.c b/drivers/regulator/rpi-panel-v2-regulator.c
> index 30b78aa75ee38..e54d675962e71 100644
> --- a/drivers/regulator/rpi-panel-v2-regulator.c
> +++ b/drivers/regulator/rpi-panel-v2-regulator.c
[ ... ]
> @@ -66,10 +67,21 @@ static int rpi_panel_v2_i2c_probe(struct i2c_client *i2c)
>  		.parent		= &i2c->dev,
>  		.reg_set_base	= REG_POWERON,
>  	};
> +	struct regulator *vcc;
>  	struct regmap *regmap;
>  	struct pwm_chip *pc;
>  	int ret;
>  
> +	vcc = devm_regulator_get(&i2c->dev, "vcc");
> +	if (IS_ERR(vcc))
> +		return dev_err_probe(&i2c->dev, PTR_ERR(vcc),
> +				     "Failed to get vcc supply\n");
> +
> +	ret = regulator_enable(vcc);
> +	if (ret)
> +		return dev_err_probe(&i2c->dev, ret,
> +				     "Failed to enable vcc supply\n");

[Severity: High]
Could this introduce a regression where a matching regulator_disable() is
missing in rpi_panel_v2_i2c_probe() for subsequent error paths and driver
remove callbacks?

> +
>  	pc = devm_pwmchip_alloc(&i2c->dev, 1, 0);
>  	if (IS_ERR(pc))
>  		return PTR_ERR(pc);

[Severity: High]
If this allocation fails in rpi_panel_v2_i2c_probe(), does the function
return directly and leak the vcc regulator enable count?

The vcc regulator's enable count is incremented via regulator_enable() but
is never decremented. When the driver unbinds or probe fails, devres calls
regulator_put(), which triggers a WARN_ON(regulator->enable_count) and
permanently leaks the underlying regulator device's use count. This prevents
the power rail from ever being physically disabled. On systems with
panic_on_warn, this triggers a kernel panic.

This regression is reachable locally via device unbind, or automatically
during boot if a downstream resource causes a probe deferral.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922-rpi_reg-v3-0-9214321c4070@oss.qualcomm.com?part=2