On 19/08/2019 15:25, Zenghui Yu wrote:
> Hi Marc,
>
> On 2019/8/6 18:01, Marc Zyngier wrote:
>> Add the required support for the ESPI range, which behave exactly like
>> the SPIs of old, only with new funky INTIDs.
>>
>> Signed-off-by: Marc Zyngier <[email protected]>
>> ---
>> drivers/irqchip/irq-gic-v3.c | 85 ++++++++++++++++++++++++------
>> include/linux/irqchip/arm-gic-v3.h | 17 +++++-
>> 2 files changed, 85 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
>> index db3bdedd7241..1ca4dde32034 100644
>> --- a/drivers/irqchip/irq-gic-v3.c
>> +++ b/drivers/irqchip/irq-gic-v3.c
>> @@ -51,13 +51,16 @@ struct gic_chip_data {
>> u32 nr_redist_regions;
>> u64 flags;
>> bool has_rss;
>> - unsigned int irq_nr;
>> struct partition_desc *ppi_descs[16];
>> };
>>
>> static struct gic_chip_data gic_data __read_mostly;
>> static DEFINE_STATIC_KEY_TRUE(supports_deactivate_key);
>>
>> +#define GIC_ID_NR (1U << GICD_TYPER_ID_BITS(gic_data.rdists.gicd_typer))
>> +#define GIC_LINE_NR GICD_TYPER_SPIS(gic_data.rdists.gicd_typer)
>
> This indicates the maximum SPI INTID that the GIC implementation
> supports, should we restrict it to no more than 1020?
I guess we could write it as max(GICD_TYPER_SPIS(...), 1020), but that's
not a material change (the registers backing the special range do exist).
> ITLinesNumber can be '11111', and I saw the following info on my host:
> "GICv3: 992 SPIs implemented"
Yeah, the above should fix the print.
Thanks,
M.
--
Jazz is not dead, it just smells funny...
