On Wed, Sep 25, 2019 at 10:17:46PM +0200, Greg Kurz wrote: > On Wed, 25 Sep 2019 16:45:25 +1000 > David Gibson <da...@gibson.dropbear.id.au> wrote: > > > spapr global irq numbers are different from the source numbers on the ICS > > when using XICS - they're offset by XICS_IRQ_BASE (0x1000). But > > spapr_irq_set_irq_xics() was passing through the global irq number to > > the ICS code unmodified. > > > > We only got away with this because of a counteracting bug - we were > > incorrectly adjusting the qemu_irq we returned for a requested global irq > > number. > > > > That approach mostly worked but is very confusing, incorrectly relies on > > the way the qemu_irq array is allocated, and undermines the intention of > > having the global array of qemu_irqs for spapr have a consistent meaning > > regardless of irq backend. > > > > So, fix both set_irq and qemu_irq indexing. We rename some parameters at > > the same time to make it clear that they are referring to spapr global > > irq numbers. > > > > Signed-off-by: David Gibson <da...@gibson.dropbear.id.au> > > --- > > Reviewed-by: Greg Kurz <gr...@kaod.org> > > Further cleanup could be to have the XICS backend to only take global > irq numbers and to convert them to ICS source numbers internally. This > would put an end to the confusion between srcno/irq in the frontend > code.
Yeah, maybe. But the local srcnos do actually make sense from within
the perspective of ICS, so I'm not all that keen to do that.
--
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
