From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 48070289E13 for ; Mon, 4 May 2026 08:46:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777884360; cv=none; b=eq8MiysnFMESjlv48tEKJlG6JSJE8Mk8ucDRaheZpQldpZizro78ehcgykAscOOEYIzWW1H5lvTvydC6PZ/MdRMFO8ymNruJSx8vfvZm5dNTTbVfoVy736w4yp8HiUthIhnZ6iVdKqq2rB/a32Wpmbk+7qJtfYmCRwxR3caPJGk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777884360; c=relaxed/simple; bh=UDq1RDYaWCjStk8E4hk5OHqI0mQrjqqEAbHXWsZuKBM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LdyR/DSLoMEywGnX6l3+AOZ0y5V44E+frUzDT7pBSKid8tOacP0X9/wX0JNfA0ga08pp6NATNPlfV3OhHkAZBdf9JbA5TnftKmc7oNMmtvxMEzcp+okXVu7F057+PHOHQ3lUIDqO8UtwOgH9vXisiv8oBAxodGEGscMoUm5Rir8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tplZwMxJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tplZwMxJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41A7EC2BCB8; Mon, 4 May 2026 08:45:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777884359; bh=UDq1RDYaWCjStk8E4hk5OHqI0mQrjqqEAbHXWsZuKBM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tplZwMxJ3opnzMO9/nHta4kU5dkZai++s1rem/crD3tBDHmVs9zdWJoovq9YvylSn PvjcGT5N+0qPKjRppLZ0L2Xzd5eRyalOgTQaFngbLicRWt8fOcH+iJVb4de8tgGv7h eJUdViKOpt2eX6QvP3Gi1ZWLilL8Yvm1bbK9O9Pw0aJCurmx0sw0a3HpQwQdEYF9GX acBm48uI9x2HLO84oyLsnxXWQZQl0XqJFMYftEfaVDeIT8NKZK5cFpT6unIbX0NXks LMvHpWDvzDkJ+dZV14vppPFKTMrjoD7F3iEI7LAiMcrMx0ZgdsEznbk6I2mROiiyek kFTCRQvWzsmCg== Date: Mon, 4 May 2026 10:45:55 +0200 From: Lorenzo Pieralisi To: Marc Zyngier Cc: Sascha Bischoff , Thomas Gleixner , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , nd Subject: Re: [PATCH 0/3] irqchip/gic-v5: Tidy up LPI allocation Message-ID: References: <20260430153352.3654325-1-sascha.bischoff@arm.com> <87cxzeayd1.wl-maz@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87cxzeayd1.wl-maz@kernel.org> 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 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 > Reviewed-by: Marc Zyngier > > Thomas, could you please take th in at the earliest opportunity? > > Thanks, > > M. > > -- > Jazz isn't dead. It just smells funny.