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 DF5A51E1E12; Wed, 30 Apr 2025 11:57:04 +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=1746014225; cv=none; b=ZjY1MvUIrDfObTaSNiOaUq7LCMZtSfZAbRxZV1Ab9RrgGRb3X+BuLcahc0B1OabuwMMJSrFsUcv1vRIVwuOMortwul2UoXfF+fDNiB29xkp/Ge0TmHorm2GkexVBgvfA9YF+nJJwwFxnrpD+5AT2JtAw65DTo00M/tRQXcYX15g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746014225; c=relaxed/simple; bh=P9vCVdJ7R9/tU4GWA/qWyC0kfWGOp24aFi3CXt4X9qU=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=JaOnWSstwC9FNMSB4XHsAq3vq3D2G5A2B3SJfpJEZqELsjkFWLOLU4+mKQuzia3f2zf7QneymWv9kATlaSgRr/p68t5+/tz7vhL0BHfbRADSk3m78xk4qmm8BRNEa9MN462dtqCEX3uYyoIpd2Fv0h6CWSV2YuzIg1KjdBhrGEg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qEIHR8NR; 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="qEIHR8NR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 44B75C4CEE9; Wed, 30 Apr 2025 11:57:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746014224; bh=P9vCVdJ7R9/tU4GWA/qWyC0kfWGOp24aFi3CXt4X9qU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qEIHR8NRDYw4Q1xD58T1jd8uLkCvW0ZH7FN0+OeIi5/br/luL4krHvTqbbZKF8BAY U7+lNcgsiCQA5QMNa/ZeV4bz0zedu9vkGWeZ3eb4fm0QDiNKIsjlRf5w3K6Sw0IusQ e+1wtgdsQOd0fyOR8PpGhAeYXIDP5sZkSvUPNG/19qx9mL1r51p5owu6vYvmLAhBY7 lXdL0XE0PizkZ1H8YV6K4Ij1eGu2eCMNnn2iXAipZ/vpCg7qYGe1VOkbJXg/QxS17a P+XaSZASgElxjnfn/xiq2IbWhu6eMktH9YCasVQBpJhoVCCV7lDB0MRxjIV8n6R+MP kjeirhZSiVpOw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uA63i-00AGFs-8s; Wed, 30 Apr 2025 12:57:02 +0100 Date: Wed, 30 Apr 2025 12:57:01 +0100 Message-ID: <867c31j20i.wl-maz@kernel.org> From: Marc Zyngier To: Lorenzo Pieralisi Cc: Thomas Gleixner , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Catalin Marinas , Will Deacon , Arnd Bergmann , Sascha Bischoff , Timothy Hayes , "Liam R. Howlett" , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v2 21/22] irqchip/gic-v5: Add GICv5 IWB support In-Reply-To: <20250424-gicv5-host-v2-21-545edcaf012b@kernel.org> References: <20250424-gicv5-host-v2-0-545edcaf012b@kernel.org> <20250424-gicv5-host-v2-21-545edcaf012b@kernel.org> 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: devicetree@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: lpieralisi@kernel.org, tglx@linutronix.de, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, sascha.bischoff@arm.com, timothy.hayes@arm.com, Liam.Howlett@oracle.com, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 24 Apr 2025 11:25:32 +0100, Lorenzo Pieralisi wrote: > > The GICv5 architecture implements the Interrupt Wire Bridge (IWB) in > order to support wired interrupts that cannot be connected directly > to an IRS and instead uses the ITS to translate a wire event into > an IRQ signal. > > An IWB is a special ITS device with its own deviceID; upon probe, > an IWB calls into the ITS driver to allocate DT/ITT tables for its > events (ie wires). > > An IWB is always associated with a single ITS in the system. > > An IWB is connected to an ITS and it has its own deviceID for all > interrupt wires that it manages; the IWB input wire number is > exposed to the ITS as an eventID. This eventID is not programmable > and therefore requires special handling in the ITS driver. > > Add an IWB driver in order to: > > - Probe IWBs in the system and allocate ITS tables > - Manage IWB IRQ domains > - Handle IWB input wires state (enable/disable) > - Add the required IWB IRQchip representation > - Handle firmware representation to Linux IRQ translation > > Co-developed-by: Sascha Bischoff > Signed-off-by: Sascha Bischoff > Co-developed-by: Timothy Hayes > Signed-off-by: Timothy Hayes > Signed-off-by: Lorenzo Pieralisi > Cc: Thomas Gleixner > Cc: Marc Zyngier > --- > drivers/irqchip/Makefile | 2 +- > drivers/irqchip/irq-gic-v5-its.c | 68 ++++++-- > drivers/irqchip/irq-gic-v5-iwb.c | 356 +++++++++++++++++++++++++++++++++++++++ > drivers/irqchip/irq-gic-v5.c | 2 + > drivers/irqchip/irq-gic-v5.h | 28 +++ > 5 files changed, 437 insertions(+), 19 deletions(-) > > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile > index 4280395e3bdff7858102f0b4eaaea1121cace52f..7bfb2369fbe494a64b72308d95ae33de93c6b8c6 100644 > --- a/drivers/irqchip/Makefile > +++ b/drivers/irqchip/Makefile > @@ -37,7 +37,7 @@ obj-$(CONFIG_ARM_GIC_V3_ITS) += irq-gic-v3-its.o irq-gic-v4.o > obj-$(CONFIG_ARM_GIC_V3_ITS_FSL_MC) += irq-gic-v3-its-fsl-mc-msi.o > obj-$(CONFIG_PARTITION_PERCPU) += irq-partition-percpu.o > obj-$(CONFIG_ARM_GIC_V5) += irq-gic-v5.o irq-gic-v5-irs.o > -obj-$(CONFIG_ARM_GIC_V5_ITS) += irq-gic-v5-its.o > +obj-$(CONFIG_ARM_GIC_V5_ITS) += irq-gic-v5-its.o irq-gic-v5-iwb.o > obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o > obj-$(CONFIG_ARM_NVIC) += irq-nvic.o > obj-$(CONFIG_ARM_VIC) += irq-vic.o > diff --git a/drivers/irqchip/irq-gic-v5-its.c b/drivers/irqchip/irq-gic-v5-its.c > index da349b4709cc5ec8978859237838f039389ca4a1..b5eb4dbfe2296dc6620889eb9291b542cae4aeb6 100644 > --- a/drivers/irqchip/irq-gic-v5-its.c > +++ b/drivers/irqchip/irq-gic-v5-its.c > @@ -786,9 +786,8 @@ static struct gicv5_its_dev *gicv5_its_find_device(struct gicv5_its_chip_data *i > return dev ? dev : ERR_PTR(-ENODEV); > } > > -static struct gicv5_its_dev *gicv5_its_alloc_device( > - struct gicv5_its_chip_data *its, int nvec, > - u32 dev_id) > +struct gicv5_its_dev *gicv5_its_alloc_device(struct gicv5_its_chip_data *its, > + int nvec, u32 dev_id, bool is_iwb) > { > struct gicv5_its_dev *its_dev; > int ret; > @@ -815,6 +814,7 @@ static struct gicv5_its_dev *gicv5_its_alloc_device( > its_dev->device_id = dev_id; > its_dev->num_events = nvec; > its_dev->num_mapped_events = 0; > + its_dev->is_iwb = is_iwb; > > ret = gicv5_its_device_register(its, its_dev); > if (ret) { > @@ -827,9 +827,11 @@ static struct gicv5_its_dev *gicv5_its_alloc_device( > > /* > * This is the first time we have seen this device. Hence, it is not > - * shared. > + * shared, unless it is an IWB that is a shared ITS device by > + * definition, its eventids are hardcoded and never change - we allocate > + * it once for all and never free it. I'm not convinced the IWB should be treated differently from any other device. Its lifetime is not tied to its inputs, so all that's needed is to probe it, get a bunch of interrupts, and that's about it. The other thing is that the IWB really is a standalone thing. It shouldn't have its fingers in the ITS code, and should only rely on the core infrastructure to get its interrupts. As much as I dislike it, the MBIGEN actually provides a decent example of how this could be structured. Thanks, M. -- Without deviation from the norm, progress is not possible.