Re: [PATCH v7 20/34] pinctrl: airoha: split driver on shared code and SoC specific drivers

[sashiko-bot@kernel.org]

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

New issues:
- [High] The trailing explicit status clear after executing `generic_handle_domain_irq()` double-ACKs edge-triggered interrupts, silencing subsequent pending edge events.
- [Medium] The driver dynamically copies an immutable `irq_chip` structure into per-instance memory, defeating the purpose of the `IRQCHIP_IMMUTABLE` flag.

Pre-existing issues:
- [High] Incorrect devres teardown ordering causes a Use-After-Free of `girq->domain` on driver unbind and a race condition during probe.
--

--- Patch [20]: [PATCH v7 20/34] pinctrl: airoha: split driver on shared code and SoC specific drivers ---
commit cead269156cfbd3a10c51e662e4e2740e945e387
Author: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

pinctrl: airoha: split driver on shared code and SoC specific drivers
    
Split combined an7581/an7583 source file on a
 * shared pinctrl code (pinctrl-airoha.c)
 * an7581 specific pinctrl driver (pinctrl-an7581.c)
 * an7583 specific pinctrl driver (pinctrl-an7583.c)

Ininialization code was adapted a bit to work properly for shared
and SoC specific cases.

> diff --git a/drivers/pinctrl/airoha/airoha-common.h b/drivers/pinctrl/airoha/airoha-common.h
> --- a/drivers/pinctrl/airoha/airoha-common.h
> +++ b/drivers/pinctrl/airoha/airoha-common.h
> @@ -148,9 +148,12 @@ struct airoha_pinctrl {
>  	struct regmap *regmap;
>  
>  	struct airoha_pinctrl_gpiochip gpiochip;
> +	struct irq_chip gpio_irq_chip;
>  };

[ ... ]

> diff --git a/drivers/pinctrl/airoha/pinctrl-airoha.c b/drivers/pinctrl/airoha/pinctrl-airoha.c
> --- a/drivers/pinctrl/airoha/pinctrl-airoha.c
> +++ b/drivers/pinctrl/airoha/pinctrl-airoha.c
> @@ -2630,9 +343,11 @@ static int airoha_pinctrl_add_gpiochip(struct airoha_pinctrl *pinctrl,
>  	gc->base = -1;
>  	gc->ngpio = AIROHA_NUM_PINS;
>  
> +	memcpy(irq_chip, &airoha_gpio_irq_chip, sizeof(struct irq_chip));
> +
>  	girq->default_type = IRQ_TYPE_NONE;
>  	girq->handler = handle_bad_irq;
> -	gpio_irq_chip_set_chip(girq, &airoha_gpio_irq_chip);
> +	gpio_irq_chip_set_chip(girq, irq_chip);

[Severity: Medium]
Does copying the immutable airoha_gpio_irq_chip into per-instance memory
bypass the protections of the IRQCHIP_IMMUTABLE flag?

The core kernel contract expects a static const irq_chip to be passed to
gpio_irq_chip_set_chip(). Here, the driver dynamically copies it into the
mutable pinctrl->gpio_irq_chip and registers that instead.

[Severity: High]
This is a pre-existing issue, but can the devres teardown order here cause
a use-after-free of the IRQ domain?

In airoha_pinctrl_add_gpiochip(), devm_request_irq() is called before
devm_gpiochip_add_data():

    err = devm_request_irq(dev, irq, airoha_irq_handler, IRQF_SHARED,
                           dev_name(dev), pinctrl);

On driver unbind, devres will execute gpiochip_remove() first (which
destroys girq->domain), and only then call free_irq(). If the shared parent
IRQ fires during this window, airoha_irq_handler() will dereference the
freed girq->domain when calling generic_handle_domain_irq().

It could also fire during probe before the domain is fully initialized.

[Severity: High]
Can the trailing status clear in airoha_irq_handler() lead to lost
edge-triggered interrupts?

Looking at airoha_irq_handler() in drivers/pinctrl/airoha/pinctrl-airoha.c:

    generic_handle_domain_irq(girq->domain, offset);
    regmap_write(pinctrl->regmap, pinctrl->gpiochip.status[i], BIT(irq));
        
This patch series updates edge-triggered interrupts to use handle_edge_irq,
which already ACKs the interrupt upfront via the .irq_ack callback. This
allows the hardware to latch new edge events while the handler runs.
However, the explicit regmap_write() after generic_handle_domain_irq()
double-ACKs the interrupt, potentially clearing any new edge events that
arrived during processing.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727074234.3761170-1-mikhail.kshevetskiy@iopsys.eu?part=20