On Tue, Feb 26, 2019 at 03:25:15PM +1100, Paul Mackerras wrote:
> On Mon, Feb 25, 2019 at 01:10:12PM +1100, David Gibson wrote:
> > On Fri, Feb 22, 2019 at 12:28:28PM +0100, Cédric Le Goater wrote:
> > > + /*
> > > + * If the source doesn't already have an IPI, allocate
> > > + * one and get the corresponding data
> > > + */
> > > + if (!state->ipi_number) {
> > > + state->ipi_number = xive_native_alloc_irq();
> > > + if (state->ipi_number == 0) {
> > > + pr_err("Failed to allocate IRQ !\n");
> > > + return -ENXIO;
> > > + }
> > > + xive_native_populate_irq_data(state->ipi_number,
> > > + &state->ipi_data);
> > > + pr_debug("%s allocated hw_irq=0x%x for irq=0x%lx\n", __func__,
> > > + state->ipi_number, irq);
> > > + }
> > > +
> > > + arch_spin_lock(&sb->lock);
> >
> > Why the direct call to arch_spin_lock() rather than just spin_lock()?
>
> He's sharing data structures with the xics-on-xive code, and that code
> has a real-mode variant, and in real mode we don't want to risk
> invoking lockdep code. Hence sb->lock is an arch_spinlock_t, and he
> has to use arch_spin_lock() on it.
Ah, right.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
