From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.9339.1643480442963850241 for ; Sat, 29 Jan 2022 10:20:43 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=kKZCw6+V; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: maz@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5CCC560B03; Sat, 29 Jan 2022 18:20:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BAE1BC340E5; Sat, 29 Jan 2022 18:20:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643480441; bh=1qaW4u53tywozVJJi68JIrt4XcjX3QpEWqUFvqdQGvE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kKZCw6+VOS/EMGlqrz/4usiF3mSQHUJrkNh6TW4RSwPAclaquviLETkFqR46I0eFT CSZOIGf8MrgHPy6BDyNWm06QroRJ29x47EyrE4ARcnUIGSUp0/1ZNDXe9m12oRdrco yB4AT+tC5bdADVGqXrD6Ha0wmYs2BHGjL0xdt1AQnB0J/FbxJicfhnvJS/a1rT1QIF U+ERZE/sjXav1PnBXOeaVmwueLV0Y0S8mTUeao+9okdOGooyAOJLY3CjggCO94hKL9 nLyWHfCMIwP/YJC9UxsNEJF6EZYuiM9XgifFgZ6+p8uMnxpw295Nkvh1vWBJvKohts 71A0p9vJcH7Sg== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nDsL1-0043a3-7U; Sat, 29 Jan 2022 18:20:39 +0000 Date: Sat, 29 Jan 2022 18:20:38 +0000 Message-ID: <87sft6xv2h.wl-maz@kernel.org> From: Marc Zyngier To: Ard Biesheuvel Cc: Pierre , edk2-devel-groups-io , Ard Biesheuvel , Sami Mujawar Subject: Re: [PATCH v3 3/8] DynamicTablesPkg: AcpiSsdtPcieLibArm: Fix _PRT description In-Reply-To: References: <20220128154103.20752-1-Pierre.Gondois@arm.com> <20220128154103.20752-4-Pierre.Gondois@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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: ardb@kernel.org, Pierre.Gondois@arm.com, devel@edk2.groups.io, ardb+tianocore@kernel.org, sami.mujawar@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Content-Type: text/plain; charset=US-ASCII On Sat, 29 Jan 2022 15:52:02 +0000, Ard Biesheuvel wrote: > > (+ Marc) > > On Fri, 28 Jan 2022 at 16:41, wrote: > > > > From: Pierre Gondois > > > > In ACPI 6.4, s6.2.13, _PRT objects describing PCI legacy interrupts > > can be defined following 2 models. > > In the first model, a _SRS object must be described to modify the PCI > > interrupt. The _CRS and _PRS object allows to describe the PCI > > interrupt (level/edge triggered, active high/low). > > In the second model, the PCI interrupt cannot be described with a > > similar granularity. PCI interrupts are by default level triggered, > > active low. > > > > GicV2 SPI interrupts are level or edge triggered, active high. To > > correctly describe PCI interrupts, the first model is used, even though > > Arm Base Boot Requirements v1.0 requires to use the second mode. > > > > There are two different issues here: > > - using separate 'interrupt link' device objects with an Interrupt() > resource rather than a simple GSIV number > - whether _PRS and _SRS need to be implemented on those link objects. > > The latter is simply not true - _PRS and _SRS are optional, and > pointless if there is only a single possible value, so there is really > no need to add them here. > > As for the choice between the link object or the GSIV number: I don't > think INTx interrupts on ARM systems are actually level low, and the > GSIV option is widely used, also in platforms that exist in > edk2-platforms, without any reported issues. > > I've cc'ed Marc, perhaps he can shed some light on this, but I'd > prefer to stick to the GSIV approach if we can, as it is much simpler. I don't immediately see the point either. Yes, the GIC only supports level-high interrupts. However, all the PCIe implementations connected to it are inverting the level. If they don't, that's even simpler (the HW is broken). Is this to address an apparent disconnect with the spec? [...] > > - The _PRS and _SRS are not supported, cf Arm Base Boot Requirements v1.0: > > + Warning: The Arm Base Boot Requirements v1.0 states the following: > > "The _PRS (Possible Resource Settings) and _SRS (Set Resource Settings) > > are not supported." > > + However, the first model to describe PCI legacy interrupts is used (cf. ACPI > > + 6.4 s6.2.13) as PCI defaults (Level Triggered, Active Low) are not compatible > > + with GICv2 (must be Active High). nit: GICv3 has the exact same behaviour. Why is v2 singled out? Thanks, M. -- Without deviation from the norm, progress is not possible.