Re: [Xen-devel] [PATCH v2 13/15] xen/arm: Merge gicv_setup with vgic_domain_init

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Ian,

On 30/06/15 13:59, Ian Campbell wrote:
> On Fri, 2015-06-26 at 10:34 +0100, Julien Grall wrote:
>> Currently, it's hard to decide whether a part of the domain
>> initialization  should live in gicv_setup (part of the GIC
>> driver) and domain_init (part of the vGIC driver).
>>
>> The code to initialize the domain for a specific vGIC version is always
>> the same no matter the version of the GIC.
>>
>> Move all the domain initialization code for the vGIC in the respective
>> domain_init callback of each vGIC drivers.
>>
>> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
>> Cc: Zoltan Kiss <zoltan.kiss@xxxxxxxxxx>
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 341b6df..3c09c3e 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -67,6 +67,11 @@ unsigned int gic_number_lines(void)
>>      return gic_hw_ops->info->nr_lines;
>>  }
>>  
>> +const struct gic_info *gic_info(void)
>> +{
>> +    return gic_hw_ops->info;
> 
> This doesn't seem to be used here. Is it a remnant of the previous
> approach?

Right, I forgot to remove it.

>> +    if ( !platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
> 
> Perhaps the stride should be in the info struct?

This is not related to any GICvN configuration but an hardware bug on
some platform (currently only xgene). And we are not immune to a similar
bug on GICv3.

So I would prefer to keep the check in vgic_domain_init which is more
self contained than spread it in different place.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel