Hi Marc,

Sorry for the constant email.

On Mon, 20 Sept 2021 at 20:24, Marc Zyngier [off-list ref] wrote:

On Mon, 20 Sep 2021 11:05:26 +0100,
Daniel Palmer [off-list ref] wrote:

quoted

Hi Marc,

On Mon, 20 Sept 2021 at 18:45, Marc Zyngier [off-list ref] wrote:

quoted

quoted

+static void ssd20xd_gpi_unmask_irq(struct irq_data *data)
+{
+     irq_hw_number_t hwirq = irqd_to_hwirq(data);
+     struct ssd20xd_gpi *gpi = irq_data_get_irq_chip_data(data);
+     int offset_reg = REG_OFFSET(hwirq);
+     int offset_bit = BIT_OFFSET(hwirq);
+
+     regmap_update_bits(gpi->regmap, REG_MASK + offset_reg, offset_bit, 0);

Is this regmap call atomic? When running this, you are holding a
raw_spinlock already. From what I can see, this is unlikely to work
correctly with the current state of regmap.

I didn't even think about it. I will check.

You may want to enable lockdep to verify that.

After some research I think this can be solved by adding
".use_raw_spinlock = true" to the regmap config to force using a
raw_spinlock instead of the default spinlock.
This avoids having a spinlock inside of a raw_spinlock.

lockdep doesn't actually complain about this currently but another
interrupt controller driver I have uses a syscon because the interrupt
registers are mixed in with unrelated stuff.
lockdep is complaining about the spinlock inside of a raw_spinlock
there. So I guess I'll need to add a new DT property for syscon to use
raw_spinlocks for that driver.

Cheers,

Daniel