Hi Marc,
Sorry for the constant email.
On Mon, 20 Sept 2021 at 20:24, Marc Zyngier <maz@xxxxxxxxxx> wrote:
>
> On Mon, 20 Sep 2021 11:05:26 +0100,
> Daniel Palmer <daniel@xxxxxxxx> wrote:
> >
> > Hi Marc,
> >
> > On Mon, 20 Sept 2021 at 18:45, Marc Zyngier <maz@xxxxxxxxxx> wrote:
> > > > +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
