Re: [PATCH v3 3/3] pps: clients: gpio: release pins to an inactive state on remove and shutdown

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] pps: probe failure in pps_gpio_setup() leaves pins in default state
--

commit c39f475f46d4d918a014f1945bfb60ecc434ce54
Author: Eliav Farber <farbere@amazon.com>

pps: clients: gpio: release pins to an inactive state on remove and shutdown

This commit introduces logic to transition PPS GPIO pins to an "inactive"
pinctrl state when the driver is unbound, shut down, or fails to probe.

> --- a/drivers/pps/clients/pps-gpio.c
> +++ b/drivers/pps/clients/pps-gpio.c

[ ... ]

> @@ -161,11 +224,16 @@ static int pps_gpio_probe(struct platform_device *pdev)
>  	if (ret)
>  		return ret;

[Severity: Medium]
If pps_gpio_setup() fails here, will this early return bypass the newly
introduced err_release_pins label? Since the pinctrl "default" state is
applied by the driver core before probe(), it seems returning directly here
might leave the hardware pins stuck in the "default" state instead of putting
them into the intended "inactive" state on probe failure.

Could pps_gpio_get_pins() be moved earlier in the probe sequence so that
the inactive state is available to be restored consistently across all failure
paths?

>  
> +	/* pinctrl setup (optional states) */
> +	ret = pps_gpio_get_pins(dev);
> +	if (ret)
> +		return ret;
> +
>  	/* IRQ setup */
>  	ret = gpiod_to_irq(data->gpio_pin);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917075611.47881-1-farbere@amazon.com?part=3