Re: [PATCH] irqchip/exynos-combiner: switch to raw_spinlock

[Thomas Gleixner <tglx@kernel.org>]

On Thu, May 21 2026 at 00:04, Marek Szyprowski wrote:

> The exynos-combiner driver uses a regular spinlock to protect access to
> the combiner interrupt status register in combiner_handle_cascade_irq(),
> which is invoked in hard IRQ context as a chained interrupt handler.
>
> When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a
> sleeping lock (mutex-based), which must not be used in atomic context
> such as hard interrupt handlers. Switch the irq_controller_lock to
> raw_spinlock, which remains a true non-sleeping spinlock even under
> PREEMPT_RT.

Mechanically this makes sense, but out of curiosity I have to ask:

> -static DEFINE_SPINLOCK(irq_controller_lock);
> +static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>  
>  struct combiner_chip_data {
>  	unsigned int hwirq_offset;
> @@ -72,9 +72,9 @@ static void combiner_handle_cascade_irq(struct irq_desc *desc)
>  
>  	chained_irq_enter(chip, desc);
>  
> -	spin_lock(&irq_controller_lock);
> +	raw_spin_lock(&irq_controller_lock);
>  	status = readl_relaxed(chip_data->base + COMBINER_INT_STATUS);
> -	spin_unlock(&irq_controller_lock);
> +	raw_spin_unlock(&irq_controller_lock);

What is this lock actually protecting?

Each combiner has it's own @base address, so there is no concurrency
problem between two cascade interrupts being handled at the same time.

That means the only possible problem would be that the same cascade
interrupt is handled on two CPUs concurrently. Is that even possible?

Thanks,

        tglx