Re: [PATCH] pinctrl: stm32: use a raw spinlock regmap to program the EXTI mux

Thank you for your contribution! Sashiko AI review found 2 potential issue(=
s) to consider:
- [High] Bypassing standard syscon regmap initialization leaves the syscfg =
clock disabled, leading to hardware bus faults on platforms where the syscf=
g node requires a clock.
- [High] If another driver sharing the syscon node probes before pinctrl, t=
he generic syscon layer will create a default regmap without `use_raw_spinl=
ock`, causing the PREEMPT_RT sleeping-in-atomic bug to persist.
--

--- Patch [1]: [PATCH] pinctrl: stm32: use a raw spinlock regmap to program=
 the EXTI mux ---
commit e662d8a81eaff2488e3427af7c289ca0a5b94fde
Author: Ju Nan <[email protected]>
Subject: pinctrl: stm32: use a raw spinlock regmap to program the EXTI mux

This commit addresses an invalid wait context issue on PREEMPT_RT by manual=
ly
publishing a regmap with use_raw_spinlock =3D true for the st,syscfg node. =
It
attempts to preempt the generic syscon layer from instantiating a default
regmap protected by a sleeping spinlock. The interrupt multiplexer is then
programmed using this raw-spinlock-protected regmap.

Closes: https://lore.kernel.org/all/20220202174430.pf37tt6lua2op3gc@pengutr=
onix.de/

> diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm3=
2/pinctrl-stm32.c
> index 6a99708a5a23c..39df117489d12 100644
> --- a/drivers/pinctrl/stm32/pinctrl-stm32.c
> +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
[ ... ]
> @@ -1757,6 +1757,68 @@ static struct irq_domain *stm32_pctrl_get_irq_doma=
in(struct platform_device *pde
[ ... ]
> +static void stm32_pctrl_publish_syscfg_regmap(struct device_node *np)
> +{
> +	struct regmap_config config =3D stm32_pctrl_syscfg_regmap_config;
> +	struct device_node *syscfg_np;
> +	struct regmap *regmap;
> +	void __iomem *base;
> +	struct resource res;
[ ... ]
> +	/*
> +	 * The regmap is handed over to the syscon layer, which never releases
> +	 * it, so it must outlive this driver: no device managed allocation
> +	 * here, and no device to attach it to either.
> +	 */
> +	regmap =3D regmap_init_mmio(NULL, base, &config);
> +	if (IS_ERR(regmap)) {
> +		iounmap(base);
> +		goto out_put;
> +	}

[Severity: High]
Does bypassing the standard syscon regmap initialization leave the syscfg
clock disabled?

The generic syscon handling normally calls of_clk_get() and=20
regmap_mmio_attach_clk(). Since this manual initialization skips that, the
clock is never attached to the regmap.

On platforms like STM32F4/F7/H7 where the syscfg node explicitly requires a=
=20
clock, could writing to the EXTI mux registers in stm32_gpio_domain_activat=
e()
with the clock disabled trigger an imprecise external abort (bus fault)?

> +
> +	/*
> +	 * A regmap is already registered for that node, most likely by the
> +	 * other pinctrl instance sharing it. Drop ours and use that one.
> +	 */
> +	if (of_syscon_register_regmap(syscfg_np, regmap)) {
> +		regmap_exit(regmap);
> +		iounmap(base);
> +	}

[Severity: High]
If another driver sharing the st,syscfg node (like Ethernet MAC, I2C, or US=
B)
probes before pinctrl, won't the generic syscon layer have already
instantiated a default regmap without use_raw_spinlock?

In that scenario, of_syscon_register_regmap() would return an error and the
driver silently discards its raw regmap. Since the driver then falls back to
the already registered sleeping regmap, does this cause the PREEMPT_RT=20
sleeping-in-atomic bug to persist when stm32_gpio_domain_activate() writes =
to
the regmap under the raw desc->lock?

> +
> +out_put:
> +	of_node_put(syscfg_np);
> +}

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803061718.4321=
[email protected]?part=3D1