Re: [PATCH v3 2/2] gpio: realtek-otto: add pinctrl support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Critical] Unconditionally enabling GPIO_GENERIC_PINCTRL_BACKEND breaks GPIO direction configuration on SoCs that do not yet have a pinctrl driver.

Pre-existing issues:
- [High] Silent failure when optional IRQ probe defers.
--

--- Patch [2]: [PATCH v3 2/2] gpio: realtek-otto: add pinctrl support ---
commit c33b7f5187bd7fe916fbf0c1df13da9be88e7f72
Author: misha.zavertkin@mail.ru <misha.zavertkin@mail.ru>

gpio: realtek-otto: add pinctrl support

This patch adds pinctrl backend support to the Realtek Otto GPIO driver.
It utilizes pinctrl to request pins for GPIO on the RTL9607C SoC.

> diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
> index 37ef56f453187..b53c2a9a04c76 100644
> --- a/drivers/gpio/gpio-realtek-otto.c
> +++ b/drivers/gpio/gpio-realtek-otto.c
> @@ -394,13 +394,14 @@ static int realtek_gpio_probe(struct platform_device *pdev)
>  
>  	raw_spin_lock_init(&ctrl->lock);
>  
> +	gen_gc_flags = GPIO_GENERIC_PINCTRL_BACKEND;
> +

[Severity: Critical]
Does setting GPIO_GENERIC_PINCTRL_BACKEND unconditionally break GPIO
direction configuration on SoCs lacking a pinctrl driver?

Because pinctrl drivers for other SoCs are not yet implemented, setting
this flag forces gpio_mmio_dir_in() and gpio_mmio_dir_out() to route via
pinctrl_gpio_direction_*(). Since no pinctrl driver is registered for those
devices, won't this fail with -EPROBE_DEFER and completely break GPIO
output/input functionality?

>  	if (dev_flags & GPIO_PORTS_REVERSED) {
> -		gen_gc_flags = 0;

[ ... ]

[Severity: High]
This is a pre-existing issue, but does the optional irq check silently
discard probe deferrals?

drivers/gpio/gpio-realtek-otto.c:realtek_gpio_probe() {
	...
	irq = platform_get_irq_optional(pdev, 0);
	if (!(dev_flags & GPIO_INTERRUPTS_DISABLED) && irq > 0) {
		girq = &ctrl->chip.gc.irq;
	...
}

When platform_get_irq_optional() returns -EPROBE_DEFER because the parent
interrupt controller is not yet ready, the irq > 0 check silently discards
the error code. This can lead to the device permanently losing GPIO
interrupt support depending on boot timing.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787209558.git.misha.zavertkin@mail.ru?part=2