From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v6 10/31] xen/arm: ITS: Introduce gic_is_lpi helper function Date: Tue, 1 Sep 2015 12:40:12 +0100 Message-ID: <55E58E9C.3040404@citrix.com> References: <1441019208-2764-1-git-send-email-vijay.kilari@gmail.com> <1441019208-2764-11-git-send-email-vijay.kilari@gmail.com> <55E48592.8080905@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Vijay Kilari Cc: Zoltan Kiss , Ian Campbell , Stefano Stabellini , Prasun Kapoor , Vijaya Kumar K , Tim Deegan , "xen-devel@lists.xen.org" , Stefano Stabellini , manish.jaggi@caviumnetworks.com List-Id: xen-devel@lists.xenproject.org On 01/09/15 10:02, Vijay Kilari wrote: > On Mon, Aug 31, 2015 at 10:19 PM, Julien Grall wrote: >> Hi Vijay, >> >> On 31/08/2015 12:06, vijay.kilari@gmail.com wrote: >>> >>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c >>> index 758678d..2199963 100644 >>> --- a/xen/arch/arm/gic.c >>> +++ b/xen/arch/arm/gic.c >>> @@ -62,6 +62,15 @@ enum gic_version gic_hw_version(void) >>> return gic_hw_ops->info->hw_version; >>> } >>> >>> +#ifdef HAS_GICV3 >>> +bool_t gic_is_lpi(unsigned int irq) >>> +{ >>> + return (irq >= FIRST_GIC_LPI && irq < (1 << >>> gic_hw_ops->info->nr_id_bits)); >> >> >> It would make more sense to calculate the number of ID supported at boot >> time rather than re-calculate everytime this function is called (i.e very >> often). >> >>> +} >>> +#else >>> +bool_t gic_is_lpi(unsigned int irq) { return 0; } >>> +#endif >> >> >> I though I'd already say it on a previous version. I would like to avoid >> seen any #ifdef HAS_GICV3 in the generic code include interrupt framework. >> >> In this case, I don't see much the benefit to do a specific case for >> platform not using GICv3 (i.e ARM32). > > You mean, let gic_is_lpi() implemented for both ARM64/32 and let this > function fail > always for ARM32? Yes. You already implement it as always fail but with #ifdef. Although I don't think this is worth to do as it's more difficult to maintain. > Other option is to implement callback to hw drivers (gicv3 and gicv2). > But overhead of callback > should also be considered It was the implementation you suggested on v5. And I wasn't not in favor about it. BTW, I suggested to create a field nr_lpis but you decided to store the number of bits supported. Why? Regards, -- Julien Grall