Re: [PATCH 3/9] dt-bindings: interrupt-controller: arm, gic-v3: Describe ESPI range support

[Lokesh Vutla]

On 23/07/19 6:45 PM, Marc Zyngier wrote:
> On 23/07/2019 13:59, Lokesh Vutla wrote:
>>
>>
>> On 23/07/19 4:14 PM, Marc Zyngier wrote:
>>> GICv3.1 introduces support for new interrupt ranges, one of them being
>>> the Extended SPI range (ESPI). The DT binding is extended to deal with
>>> it as a new interrupt class.
>>>
>>> Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx>
>>> ---
>>>  .../devicetree/bindings/interrupt-controller/arm,gic-v3.yaml | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
>>> index c34df35a25fc..98a3ecda8e07 100644
>>> --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
>>> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
>>> @@ -44,11 +44,12 @@ properties:
>>>        be at least 4.
>>>  
>>>        The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>>> -      interrupts. Other values are reserved for future use.
>>> +      interrupts, 2 for interrupts in the Extended SPI range. Other values
>>> +      are reserved for future use.
>>
>> Any reason why hardware did not consider extending SPIs from 1020:2043? This way
>> only EPPI would have been introduced. Just a thought.
> 
> First, 1020-1023 is the special INTID range. You can't have anything
> else there.
> 
> Then, making the range contiguous could imply that the range is also
> contiguous in the register space, which isn't possible (note that the
> EPPI range does it the other way around -- it is discontinuous in the
> INTID space, and yet continuous in the register space).
> 
> Finally, the decision to push the numbering out towards the LPI range
> allows the ESPI space to be grown easily up to 4k.

okay, got it.

> 
> But frankly, none of that really matters. They are just numbers.
> 
>> Either ways, just to be consistent with hardware numbering can ESPI range be 3
>> and EPPI range be 2?
> 
> Well, the way I see it is that it is more logical for the binding
> itself. We already have 0 for SPIs and 1 for PPIs, despite PPIs being
> before SPIs in the INTID space.

Agreed. Patch looks good to me. FWIW:

Reviewed-by: Lokesh Vutla <lokeshvutla@xxxxxx>

Thanks and regards,
Lokesh

> 
> Thanks,
> 
> 	M.
>