Re: [PATCH v10 21/36] pinctrl: airoha: remove not needed irq_type[] array

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The irqchip callbacks (airoha_irq_unmask, airoha_irq_mask, airoha_irq_ack) call regmap functions which take a spinlock while running under the raw_spinlock_t of the irq descriptor, leading to lock nesting violations on non-RT (with PROVE_RAW_LOCK_NESTING) and deadlocks/sleeping-in-atomic on PREEMPT_RT.
--

--- Patch [21]: [PATCH v10 21/36] pinctrl: airoha: remove not needed irq_type[] array ---
commit c04f7b2c079eefe11ed72d70dd01520d657ba1d1
Author: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

pinctrl: airoha: remove not needed irq_type[] array

The irq_type[] array inside airoha_pinctrl_gpiochip structure is not
actually necessary. This commit removes it and uses the trigger type
from struct irq_data instead.

> 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

[ ... ]

> @@ -2628,7 +2626,7 @@ static void airoha_irq_mask(struct irq_data *data)
>  	u8 index = data->hwirq / AIROHA_REG_GPIOCTRL_NUM_PIN;
>  	u32 mask = GENMASK(2 * offset + 1, 2 * offset);
>  
> -	if (data->hwirq >= ARRAY_SIZE(gpiochip->irq_type))
> +	if (data->hwirq >= AIROHA_NUM_PINS)
>  		return;
>  
>  	regmap_clear_bits(pinctrl->regmap, gpiochip->level[index], mask);

[Severity: High]
This is a pre-existing issue, but does calling regmap functions here cause a
lock nesting violation?

The IRQ subsystem invokes callbacks like airoha_irq_mask(),
airoha_irq_unmask(), and airoha_irq_ack() while holding desc->lock, which is a
raw_spinlock_t. Inside these callbacks, the code calls regmap_clear_bits() and
regmap_write() on pinctrl->regmap.

Syscon regmaps default to a standard spinlock_t. Acquiring a spinlock_t while
holding a raw spinlock can lead to lockdep warnings on non-RT kernels, and
sleeping in atomic context or deadlocks on PREEMPT_RT where spinlock_t becomes
a sleepable lock.

Could this regmap be configured to use a raw spinlock, or could these register
accesses be handled outside the raw spinlock context?

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