LPIs are owned by the LPI domain, so allocating and freeing them from
the ITS MSI and IPI domains was always a bit backwards. Those domains
should only ask their parent for interrupts, and never need to
know how the parent picks or releases the underlying LPIs (or do it on
behalf of said parent, as was the case).

This series moves LPI allocation into the LPI domain itself and
removes the exported wrappers that allowed LPI allocation from elsewhere.

With that done, the LPI domain can also be slightly reworked to
support allocating and freeing more than one LPI at a time. This
rework is extended to the IPI allocation, too. The last patch makes
the ITS MSI domain request its parent interrupts as a single range,
matching the IPI cleanup from the previous patch.

As a side effect of these changes, the IPI path now unwinds earlier
parent allocations correctly if a later allocation fails.

Thanks,
Sascha

Sascha Bischoff (3):
  irqchip/gic-v5: Move LPI alloc/free into LPI domain
  irqchip/gic-v5: Allow for nr_irqs > 1 for LPI alloc and teardown
  irqchip/gic-v5: Allocate ITS parent LPIs as a range

 drivers/irqchip/irq-gic-v5-its.c   | 34 +++--------
 drivers/irqchip/irq-gic-v5.c       | 90 ++++++++++++++++--------------
 include/linux/irqchip/arm-gic-v5.h |  3 -
 3 files changed, 56 insertions(+), 71 deletions(-)

-- 
2.34.1

Hi Sascha,

On Thu, 30 Apr 2026 16:33:58 +0100,
Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
> 
> LPIs are owned by the LPI domain, so allocating and freeing them from
> the ITS MSI and IPI domains was always a bit backwards. Those domains
> should only ask their parent for interrupts, and never need to
> know how the parent picks or releases the underlying LPIs (or do it on
> behalf of said parent, as was the case).
> 
> This series moves LPI allocation into the LPI domain itself and
> removes the exported wrappers that allowed LPI allocation from elsewhere.
> 
> With that done, the LPI domain can also be slightly reworked to
> support allocating and freeing more than one LPI at a time. This
> rework is extended to the IPI allocation, too. The last patch makes
> the ITS MSI domain request its parent interrupts as a single range,
> matching the IPI cleanup from the previous patch.
> 
> As a side effect of these changes, the IPI path now unwinds earlier
> parent allocations correctly if a later allocation fails.

Thanks for cleaning up this mess. It aligns the GICv5 host code with
the expectations we have for hierarchical domains (don't mess with
your parent's allocations), and will make the KVM management of
doorbell LPIs less awkward. It also removes global helpers that always
irked me, so:

Reviewed-by: Marc Zyngier <maz@kernel.org>

Thomas, could you please take th in at the earliest opportunity?

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.

On Sat, May 02, 2026 at 11:40:10AM +0100, Marc Zyngier wrote:
> Hi Sascha,
> 
> On Thu, 30 Apr 2026 16:33:58 +0100,
> Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
> > 
> > LPIs are owned by the LPI domain, so allocating and freeing them from
> > the ITS MSI and IPI domains was always a bit backwards. Those domains
> > should only ask their parent for interrupts, and never need to
> > know how the parent picks or releases the underlying LPIs (or do it on
> > behalf of said parent, as was the case).
> > 
> > This series moves LPI allocation into the LPI domain itself and
> > removes the exported wrappers that allowed LPI allocation from elsewhere.
> > 
> > With that done, the LPI domain can also be slightly reworked to
> > support allocating and freeing more than one LPI at a time. This
> > rework is extended to the IPI allocation, too. The last patch makes
> > the ITS MSI domain request its parent interrupts as a single range,
> > matching the IPI cleanup from the previous patch.
> > 
> > As a side effect of these changes, the IPI path now unwinds earlier
> > parent allocations correctly if a later allocation fails.
> 
> Thanks for cleaning up this mess. It aligns the GICv5 host code with
> the expectations we have for hierarchical domains (don't mess with
> your parent's allocations), and will make the KVM management of
> doorbell LPIs less awkward. It also removes global helpers that always
> irked me, so:

Bah, sorry, it not only breaks the IRQ domains expectations but
the current allocation is really braindead - I was too fixated on
the IDA 1 by 1 allocation (that should really disappear asap) that
I could not see the wood for the trees.

Thank you Sascha for cleaning it up.

Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>

> Reviewed-by: Marc Zyngier <maz@kernel.org>
> 
> Thomas, could you please take th in at the earliest opportunity?
> 
> Thanks,
> 
> 	M.
> 
> -- 
> Jazz isn't dead. It just smells funny.

On Mon, 2026-05-04 at 10:45 +0200, Lorenzo Pieralisi wrote:
> On Sat, May 02, 2026 at 11:40:10AM +0100, Marc Zyngier wrote:
> > Hi Sascha,
> > 
> > On Thu, 30 Apr 2026 16:33:58 +0100,
> > Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
> > > 
> > > LPIs are owned by the LPI domain, so allocating and freeing them
> > > from
> > > the ITS MSI and IPI domains was always a bit backwards. Those
> > > domains
> > > should only ask their parent for interrupts, and never need to
> > > know how the parent picks or releases the underlying LPIs (or do
> > > it on
> > > behalf of said parent, as was the case).
> > > 
> > > This series moves LPI allocation into the LPI domain itself and
> > > removes the exported wrappers that allowed LPI allocation from
> > > elsewhere.
> > > 
> > > With that done, the LPI domain can also be slightly reworked to
> > > support allocating and freeing more than one LPI at a time. This
> > > rework is extended to the IPI allocation, too. The last patch
> > > makes
> > > the ITS MSI domain request its parent interrupts as a single
> > > range,
> > > matching the IPI cleanup from the previous patch.
> > > 
> > > As a side effect of these changes, the IPI path now unwinds
> > > earlier
> > > parent allocations correctly if a later allocation fails.
> > 
> > Thanks for cleaning up this mess. It aligns the GICv5 host code
> > with
> > the expectations we have for hierarchical domains (don't mess with
> > your parent's allocations), and will make the KVM management of
> > doorbell LPIs less awkward. It also removes global helpers that
> > always
> > irked me, so:
> 
> Bah, sorry, it not only breaks the IRQ domains expectations but
> the current allocation is really braindead - I was too fixated on
> the IDA 1 by 1 allocation (that should really disappear asap) that
> I could not see the wood for the trees.
> 
> Thank you Sascha for cleaning it up.

No worries at all. Frankly, it is a hangover from early prototyping,
and hence my fault to begin with!

Thanks for taking the time to review this, both.

Sascha

> 
> Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> 
> > Reviewed-by: Marc Zyngier <maz@kernel.org>
> > 
> > Thomas, could you please take th in at the earliest opportunity?
> > 
> > Thanks,
> > 
> > 	M.
> > 
> > -- 
> > Jazz isn't dead. It just smells funny.