[PATCH] pinctrl: meson: amlogic-a4: fix gpio output glitch

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incomplete fix: The GPIO output glitch bug is identically present in the core `pinctrl-meson.c` driver, leaving other Amlogic SoCs vulnerable.
- [High] AA deadlock in `aml_pinconf_set_*` functions triggerable from userspace via GPIO character device.
--

commit 91d93a06a0e9681b94621504af7968b8a6f4f155
Author: Xianwei Zhao <xianwei.zhao at amlogic.com>

pinctrl: meson: amlogic-a4: fix gpio output glitch

This commit fixes a brief low-level glitch on GPIO lines during the
transition from bootloader to kernel. It does this by swapping the
configuration order to set the output value before switching the pin
direction to output.

> diff --git a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c b/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
> index 35d27626a336b..1bd58fbbd26ac 100644
> --- a/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
> +++ b/drivers/pinctrl/meson/pinctrl-amlogic-a4.c
> @@ -548,11 +548,11 @@ static int aml_pinconf_set_output_drive(struct aml_pinctrl *info,
>  {
>  	int ret;
>  
> -	ret = aml_pinconf_set_output(info, pin, true);
> +	ret = aml_pinconf_set_drive(info, pin, high);

Does this call chain trigger an AA deadlock when configured at runtime?

When a GPIO line's configuration is changed from userspace (for example, via
the GPIO_V2_LINE_SET_CONFIG_IOCTL), the core pinctrl_gpio_set_config()
function acquires pctldev->mutex before invoking the .pin_config_set callback.

If aml_pinconf_set_drive() calls aml_pinconf_set_gpio_bit(), and that function
still uses pinctrl_find_gpio_range_from_pin(), it will attempt to acquire the
same pctldev->mutex.

A previous commit fixed a similar deadlock for the _get functions by switching
to pinctrl_find_gpio_range_from_pin_nolock(). Do the _set functions need the
same update?

Additionally, while this resolves the glitch for the amlogic-a4 driver, does
the core pinctrl-meson.c driver have the same issue? Looking at
meson_pinconf_set_output_drive() in the core driver, it appears to still
call meson_pinconf_set_output() before meson_pinconf_set_drive(). Could
other Amlogic SoCs be vulnerable to the same regulator control glitch
unless the order is swapped there as well?

>  	if (ret)
>  		return ret;
>  
> -	return aml_pinconf_set_drive(info, pin, high);
> +	return aml_pinconf_set_output(info, pin, true);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518-fix-set-value-glitch-v1-1-d350732dc934@amlogic.com?part=1