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 6C724274B2A for ; Sat, 2 May 2026 10:40:13 +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=1777718413; cv=none; b=V9oIuQIaUcAl09Rxdpw9lu3AVk4SyWcfWtyhJgAH9VsWo6bcz9RRQSh2lxu+Q58nUL/0WtUSKGN20pvIQD2gEorKyF6FdutkzI8+MXbljiwkjLYbzTee4tPx2M2mOJG+Uo5rrouHp0a4hgs2xGkqQWvBJiQt2jlyckrJwjz/q6Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777718413; c=relaxed/simple; bh=5hGrX1n4wF59Q8/Dj57P146EcinwPZ+zWpBBXfPxm34=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=sIB7fC8BlrpGcmEFX231fqZJFfrH02luj1BxGGrBZF0dY6hE5+CqrbfWh3irjd1+7r8tmVrqfvQwxdGBbZVB/hD9/Yc4ddC00wDdaQbi9C4ke1RP8enCz8xG/Ncu7DQnIpldMGxWNYcQoHP4pd/SMwssk9LplDo61rR162G1au4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E1iOK+Q6; 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="E1iOK+Q6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05A5AC19425; Sat, 2 May 2026 10:40:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777718413; bh=5hGrX1n4wF59Q8/Dj57P146EcinwPZ+zWpBBXfPxm34=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=E1iOK+Q65LVUu1hsaHcyzmolI/YbyIP9NQUDVN5xxMfOs2DRmZv2spjGMbtjaxxJq QV1CbXNijciGY7h8JsRx65JfZ2CebcfbKi1Ro+CnwIjCPaF0HwaVDr7aa27rPjsBJV 5/ib/nrLaL4ECdcX3oYfZLO9Tq/yKCVasbRM2jKR8DbOOwVcFdO7iK9VcqQSYwap4z 4OEDwzRA6NBh6/n3rAzdD6MA1f0xdjkiVv/rZq3XzafwzPKBZHLVh1FzqB53wxj+sZ JQGXw1cdW12Ij0YJHMBpgljOjksSf6YxFm0ccE2HIerACw3jKaUaQ8KDnWwJ3S3Db5 YNkjs7hc8/atw== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wJ7la-0000000Gjv6-2zOd; Sat, 02 May 2026 10:40:10 +0000 Date: Sat, 02 May 2026 11:40:10 +0100 Message-ID: <87cxzeayd1.wl-maz@kernel.org> From: Marc Zyngier To: Sascha Bischoff , Thomas Gleixner Cc: "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , nd , Lorenzo Pieralisi Subject: Re: [PATCH 0/3] irqchip/gic-v5: Tidy up LPI allocation In-Reply-To: <20260430153352.3654325-1-sascha.bischoff@arm.com> References: <20260430153352.3654325-1-sascha.bischoff@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: Sascha.Bischoff@arm.com, tglx@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, nd@arm.com, lpieralisi@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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: 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.