[PATCH] gpio: mvebu: fix sleeping-while-atomic in mvebu_gpio_level_irq_mask()

[PATCH] gpio: mvebu: fix sleeping-while-atomic in mvebu_gpio_level_irq_mask()

[Bartosz Golaszewski]

mvebu_gpio_write_level_mask() is called with a raw spinlock taken but
the underlying regmap uses a standard spinlock which can sleep on
RT_PREEMPT kernels. Add the .use_raw_spinlock attribute to the
appropriate regmap config.

Cc: stable@vger.kernel.org
Fixes: 48f32a835373 ("gpio: mvebu: switch pwm duration registers to regmap")
Closes: https://sashiko.dev/#/bug/linux-6bee0c4f-384c-494c-868e-07c420195d13
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/gpio/gpio-mvebu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 267e6d5bacd0d1c9de0ebb7e21233bc9e2cd3bad..02d9ae5869d75ccc9ac78c41650b9f21b18ffdaa 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -603,6 +603,7 @@ static const struct regmap_config mvebu_gpio_regmap_config = {
 	.reg_bits = 32,
 	.reg_stride = 4,
 	.val_bits = 32,
+	.use_raw_spinlock = true,
 };
 
 static const struct regmap_config mvebu_gpio_percpu_regmap_config = {

---
base-commit: 8b7179210b22f8e48a82c5ceacb9d56a9c4cfec4
change-id: 20261105-gpio-mvebu-sleeping-while-atomic-3b3fed029f7b

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Re: [PATCH] gpio: mvebu: fix sleeping-while-atomic in mvebu_gpio_level_irq_mask()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] gpio: mvebu: missing use_raw_spinlock in mvebu_gpio_percpu_regmap_config
--

commit 7ad64e668b066c72ed4810dd8de43859b3810544
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

gpio: mvebu: fix sleeping-while-atomic in mvebu_gpio_level_irq_mask()

This commit sets use_raw_spinlock on mvebu_gpio_regmap_config to avoid
taking a sleepable spinlock_t on PREEMPT_RT kernels when accessing GPIO
registers while holding a raw_spinlock_t in the IRQ callbacks.

> diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
> index 267e6d5bacd0d..02d9ae5869d75 100644
> --- a/drivers/gpio/gpio-mvebu.c
> +++ b/drivers/gpio/gpio-mvebu.c
> @@ -603,6 +603,7 @@ static const struct regmap_config mvebu_gpio_regmap_config = {
>  	.reg_bits = 32,
>  	.reg_stride = 4,
>  	.val_bits = 32,
> +	.use_raw_spinlock = true,
>  };
>  
>  static const struct regmap_config mvebu_gpio_percpu_regmap_config = {

[Severity: High]
Should mvebu_gpio_percpu_regmap_config also set .use_raw_spinlock = true?

In mvebu_gpio_probe_raw(), mvchip->percpu_regs is initialized with
mvebu_gpio_percpu_regmap_config:

	mvchip->percpu_regs =
		devm_regmap_init_mmio(&pdev->dev, base,
				      &mvebu_gpio_percpu_regmap_config);

When mvchip->soc_variant is MVEBU_GPIO_SOC_VARIANT_ARMADAXP,
mvebu_gpioreg_level_mask(), mvebu_gpioreg_edge_mask(), and
mvebu_gpioreg_edge_cause() select mvchip->percpu_regs instead of
mvchip->regs:

	case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
		cpu = smp_processor_id();
		*map = mvchip->percpu_regs;
		*offset = GPIO_LEVEL_MASK_ARMADAXP_OFF(cpu);
		break;

The irq_chip callbacks mvebu_gpio_level_irq_mask(),
mvebu_gpio_level_irq_unmask(), mvebu_gpio_edge_irq_mask(),
mvebu_gpio_edge_irq_unmask(), and mvebu_gpio_irq_ack() acquire the raw
spinlock gc->lock before calling mvebu_gpio_write_level_mask(),
mvebu_gpio_write_edge_mask(), or mvebu_gpio_write_edge_cause(), and
mvebu_gpio_irq_handler() reads these registers in hardirq context. Without
use_raw_spinlock on mvebu_gpio_percpu_regmap_config, won't Armada XP
systems still hit the same sleeping-while-atomic issue on PREEMPT_RT?

Also, the IRQ callbacks were converted to regmap in commit 2233bf7a92e7
("gpio: mvebu: convert to regmap") and mvebu_gpio_percpu_regmap_config was
split out in commit 4d305c227312 ("gpio: mvebu: name regmaps"), whereas
commit 48f32a835373 ("gpio: mvebu: switch pwm duration registers to
regmap") only moved mvebu_gpio_regmap_config earlier in the file. Should
the Fixes tag reference those commits instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105-gpio-mvebu-sleeping-while-atomic-v1-1-3ad7bb1c9e36@oss.qualcomm.com?part=1