Re: [PATCH] pinctrl: rk805: fix ordering of gpio and pinctrl registration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pinctrl: rk805: NULL dereference in gpiochip_get_data() via pinconf
--

commit a49ae4e9bf527300ce287085a0623b150f2db443
Author: Heiko Stuebner <heiko.stuebner@cherry.de>

pinctrl: rk805: fix ordering of gpio and pinctrl registration

This commit reorders rk805_pinctrl_probe() so that devm_pinctrl_register() is
called before devm_gpiochip_add_data(), ensuring the GPIO chip and its pin
ranges are torn down before the pinctrl device during devres release.

> diff --git a/drivers/pinctrl/pinctrl-rk805.c b/drivers/pinctrl/pinctrl-rk805.c
> index 22f576337faa9..8e04da3ef0f3a 100644
> --- a/drivers/pinctrl/pinctrl-rk805.c
> +++ b/drivers/pinctrl/pinctrl-rk805.c
> @@ -663,13 +663,6 @@ static int rk805_pinctrl_probe(struct platform_device *pdev)
>  		return -EINVAL;
>  	}
>  
> -	/* Add gpio chip */
> -	ret = devm_gpiochip_add_data(&pdev->dev, &pci->gpio_chip, pci);
> -	if (ret < 0) {
> -		dev_err(&pdev->dev, "Couldn't add gpiochip\n");
> -		return ret;
> -	}
> -
>  	/* Add pinctrl */
>  	pci->pctl = devm_pinctrl_register(&pdev->dev, &pci->pinctrl_desc, pci);
>  	if (IS_ERR(pci->pctl)) {
> @@ -677,6 +670,13 @@ static int rk805_pinctrl_probe(struct platform_device *pdev)
>  		return PTR_ERR(pci->pctl);
>  	}
>  
> +	/* Add gpio chip */
> +	ret = devm_gpiochip_add_data(&pdev->dev, &pci->gpio_chip, pci);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "Couldn't add gpiochip\n");
> +		return ret;
> +	}

[Severity: High]
Can registering pinctrl before the gpio_chip cause a NULL pointer dereference
in gpiochip_get_data() when pinconf callbacks run?

In rk805_pinctrl_probe(), device_set_node() attaches the parent PMIC fwnode to
pdev->dev, and devm_pinctrl_register() immediately claims default pinctrl hogs
via:

  devm_pinctrl_register()
    pinctrl_register()
      pinctrl_enable()
        pinctrl_claim_hogs()
          create_pinctrl()
          pinctrl_select_state()
            pinctrl_commit_state()
              pinconf_apply_setting()
                rk805_pinconf_set()

Both rk805_pinconf_set() and rk805_pinconf_get() delegate PIN_CONFIG_LEVEL
(and PIN_CONFIG_INPUT_ENABLE in rk805_pinconf_get()) to rk805_gpio_set() and
rk805_gpio_get(), passing &pci->gpio_chip:

drivers/pinctrl/pinctrl-rk805.c:rk805_pinconf_set() {
	...
		switch (param) {
		case PIN_CONFIG_LEVEL:
			rk805_gpio_set(&pci->gpio_chip, pin, arg);
			rk805_pmx_gpio_set_direction(pctldev, NULL, pin, false);
			break;
	...
}

drivers/pinctrl/pinctrl-rk805.c:rk805_gpio_set() {
	struct rk805_pctrl_info *pci = gpiochip_get_data(chip);
	...
}

drivers/gpio/gpiolib.c:gpiochip_get_data() {
	return gc->gpiodev->data;
}

Because devm_gpiochip_add_data() has not run yet when devm_pinctrl_register()
is called, pci->gpio_chip.gpiodev is still NULL. If a default hog state on the
PMIC node sets output-low or output-high, or if a consumer or debugfs reader
queries pinconf before devm_gpiochip_add_data() completes (or during unbind
after devm_gpio_chip_release() clears gc->gpiodev->data), wouldn't
gpiochip_get_data() dereference a NULL pointer?

Would it be safer for rk805_pinconf_get() and rk805_pinconf_set() to use a
helper that takes struct rk805_pctrl_info *pci directly (obtained via
pinctrl_dev_get_drvdata(pctldev)) rather than going through
&pci->gpio_chip and gpiochip_get_data()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261030115540.3660242-1-heiko@sntech.de?part=1