[15/21] dt-bindings: irqchip/atmel-aic5: Add support for sam9x7 aic

  Document the support added for the Advanced interrupt controller(AIC)
chip in the sam9x7 soc family

Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
---
 .../devicetree/bindings/interrupt-controller/atmel,aic.txt      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

Hey Varshini,

On Sun, Jun 04, 2023 at 01:32:37AM +0530, Varshini Rajendran wrote:
> Document the support added for the Advanced interrupt controller(AIC)
> chip in the sam9x7 soc family

Please do not add new family based compatibles, but rather use per-soc
compatibles instead.

Cheers,
Conor.

> 
> Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
> ---
>  .../devicetree/bindings/interrupt-controller/atmel,aic.txt      | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt
> index 7079d44bf3ba..2c267a66a3ea 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt
> @@ -4,7 +4,7 @@ Required properties:
>  - compatible: Should be:
>      - "atmel,<chip>-aic" where  <chip> can be "at91rm9200", "sama5d2",
>        "sama5d3" or "sama5d4"
> -    - "microchip,<chip>-aic" where <chip> can be "sam9x60"
> +    - "microchip,<chip>-aic" where <chip> can be "sam9x60", "sam9x7"
>  
>  - interrupt-controller: Identifies the node as an interrupt controller.
>  - #interrupt-cells: The number of cells to define the interrupts. It should be 3.
> -- 
> 2.25.1
>
  

On Sat, Jun 03, 2023 at 10:19:50PM +0100, Conor Dooley wrote:
> Hey Varshini,
> 
> On Sun, Jun 04, 2023 at 01:32:37AM +0530, Varshini Rajendran wrote:
> > Document the support added for the Advanced interrupt controller(AIC)
> > chip in the sam9x7 soc family
> 
> Please do not add new family based compatibles, but rather use per-soc
> compatibles instead.

These things leave me penally confused. Afaiu, sam9x60 is a particular
SoC. sam9x7 is actually a family, containing sam9x70, sam9x72 and
sam9x75. It would appear to me that each should have its own compatible,
no?

> 
> Cheers,
> Conor.
> 
> > 
> > Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
> > ---
> >  .../devicetree/bindings/interrupt-controller/atmel,aic.txt      | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt
> > index 7079d44bf3ba..2c267a66a3ea 100644
> > --- a/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt
> > @@ -4,7 +4,7 @@ Required properties:
> >  - compatible: Should be:
> >      - "atmel,<chip>-aic" where  <chip> can be "at91rm9200", "sama5d2",
> >        "sama5d3" or "sama5d4"
> > -    - "microchip,<chip>-aic" where <chip> can be "sam9x60"
> > +    - "microchip,<chip>-aic" where <chip> can be "sam9x60", "sam9x7"
> >  
> >  - interrupt-controller: Identifies the node as an interrupt controller.
> >  - #interrupt-cells: The number of cells to define the interrupts. It should be 3.
> > -- 
> > 2.25.1
> >
  

On Sat, Jun 3, 2023, at 23:23, Conor Dooley wrote:
> On Sat, Jun 03, 2023 at 10:19:50PM +0100, Conor Dooley wrote:
>> Hey Varshini,
>> 
>> On Sun, Jun 04, 2023 at 01:32:37AM +0530, Varshini Rajendran wrote:
>> > Document the support added for the Advanced interrupt controller(AIC)
>> > chip in the sam9x7 soc family
>> 
>> Please do not add new family based compatibles, but rather use per-soc
>> compatibles instead.
>
> These things leave me penally confused. Afaiu, sam9x60 is a particular
> SoC. sam9x7 is actually a family, containing sam9x70, sam9x72 and
> sam9x75. It would appear to me that each should have its own compatible,
> no?

I think the usual way this works is that the sam9x7 refers to the
SoC design as in what is actually part of the chip, whereas the 70,
72 and 75 models are variants that have a certain subset of the
features enabled.

If that is the case here, then referring to the on-chip parts by
the sam9x7 name makes sense, and this is similar to what we do
on TI AM-series chips.

There is a remaining risk that a there would be a future
sam9x71/73/74/76/... product based on a new chip that uses
incompatible devices, but at that point we can still use the
more specific model number to identify those without being
ambiguous. The same thing can of course happen when a SoC
vendor reuses a specific name of a prior product with an update
chip that has software visible changes.

I'd just leave this up to Varshini and the other at91 maintainers
here, provided they understand the exact risks.

It's different for the parts that are listed as just sam9x60
compatible in the DT, I think those clearly need to have sam9x7
in the compatible list, but could have the sam9x60 identifier
as a fallback if the hardware is compatible.

     Arnd
  

On Sun, Jun 04, 2023 at 11:49:48AM +0200, Arnd Bergmann wrote:
> On Sat, Jun 3, 2023, at 23:23, Conor Dooley wrote:
> > On Sat, Jun 03, 2023 at 10:19:50PM +0100, Conor Dooley wrote:
> >> Hey Varshini,
> >> 
> >> On Sun, Jun 04, 2023 at 01:32:37AM +0530, Varshini Rajendran wrote:
> >> > Document the support added for the Advanced interrupt controller(AIC)
> >> > chip in the sam9x7 soc family
> >> 
> >> Please do not add new family based compatibles, but rather use per-soc
> >> compatibles instead.
> >
> > These things leave me penally confused. Afaiu, sam9x60 is a particular

s/penally/perennially/

> > SoC. sam9x7 is actually a family, containing sam9x70, sam9x72 and
> > sam9x75. It would appear to me that each should have its own compatible,
> > no?
> 
> I think the usual way this works is that the sam9x7 refers to the
> SoC design as in what is actually part of the chip, whereas the 70,
> 72 and 75 models are variants that have a certain subset of the
> features enabled.
> 
> If that is the case here, then referring to the on-chip parts by
> the sam9x7 name makes sense, and this is similar to what we do
> on TI AM-series chips.

If it is the case that what differentiates them is having bits chopped
off, and there's no implementation differences that seems fair.

> There is a remaining risk that a there would be a future
> sam9x71/73/74/76/... product based on a new chip that uses
> incompatible devices, but at that point we can still use the
> more specific model number to identify those without being
> ambiguous. The same thing can of course happen when a SoC
> vendor reuses a specific name of a prior product with an update
> chip that has software visible changes.
> 
> I'd just leave this up to Varshini and the other at91 maintainers
> here, provided they understand the exact risks.

Ye, seems fair to me. Nicolas/Claudiu etc, is there a convention to use
the "0" model as the compatible (like the 9x60 did) or have "random"
things been done so far?

> It's different for the parts that are listed as just sam9x60
> compatible in the DT, I think those clearly need to have sam9x7
> in the compatible list, but could have the sam9x60 identifier
> as a fallback if the hardware is compatible.

Aye.
  

Arnd, Conor,

On 04/06/2023 at 23:08, Conor Dooley wrote:
> On Sun, Jun 04, 2023 at 11:49:48AM +0200, Arnd Bergmann wrote:
>> On Sat, Jun 3, 2023, at 23:23, Conor Dooley wrote:
>>> On Sat, Jun 03, 2023 at 10:19:50PM +0100, Conor Dooley wrote:
>>>> Hey Varshini,
>>>>
>>>> On Sun, Jun 04, 2023 at 01:32:37AM +0530, Varshini Rajendran wrote:
>>>>> Document the support added for the Advanced interrupt controller(AIC)
>>>>> chip in the sam9x7 soc family
>>>> Please do not add new family based compatibles, but rather use per-soc
>>>> compatibles instead.
>>> These things leave me penally confused. Afaiu, sam9x60 is a particular
> s/penally/perennially/
> 
>>> SoC. sam9x7 is actually a family, containing sam9x70, sam9x72 and
>>> sam9x75. It would appear to me that each should have its own compatible,
>>> no?
>> I think the usual way this works is that the sam9x7 refers to the
>> SoC design as in what is actually part of the chip, whereas the 70,
>> 72 and 75 models are variants that have a certain subset of the
>> features enabled.

Yes, That's the case.
>> If that is the case here, then referring to the on-chip parts by
>> the sam9x7 name makes sense, and this is similar to what we do
>> on TI AM-series chips.

This is what we did for most of our SoCs families, indeed.

> If it is the case that what differentiates them is having bits chopped
> off, and there's no implementation differences that seems fair.

Ok, thanks.

>> There is a remaining risk that a there would be a future
>> sam9x71/73/74/76/... product based on a new chip that uses
>> incompatible devices, but at that point we can still use the
>> more specific model number to identify those without being
>> ambiguous. 

This is exactly what we did for sama5d29 which is not the same silicon 
vs. the other members of the sama5d2 family. We used the more specify 
sama5d29 sub-string for describing the changing parts (CAN-FD and Ethernet).

>> The same thing can of course happen when a SoC
>> vendor reuses a specific name of a prior product with an update
>> chip that has software visible changes.
>>
>> I'd just leave this up to Varshini and the other at91 maintainers
>> here, provided they understand the exact risks.

Yep, I understand the risk and will try to review the compatibility 
strings that would need more precise description (maybe PMC or AIC).

> Ye, seems fair to me. Nicolas/Claudiu etc, is there a convention to use
> the "0" model as the compatible (like the 9x60 did) or have "random"
> things been done so far?

sam9x60 was a single SoC, not a member of a "family", so there was no 
meaning of the "0" here. Moreover, the "0" ones are usually not the 
subset, if it even exists.
So far, we used the silicon string to define the compatibility string, 
adding a more precise string for hardware of family members that needed 
it (as mentioned above for sama5d29).

>> It's different for the parts that are listed as just sam9x60
>> compatible in the DT, I think those clearly need to have sam9x7
>> in the compatible list, but could have the sam9x60 identifier
>> as a fallback if the hardware is compatible.
> Aye.

Yep, agreed.

Thanks for your help. Best regards,
   Nicolas
  

On Mon, Jun 05, 2023 at 02:37:16PM +0200, Nicolas Ferre wrote:
> Arnd, Conor,
> 
> On 04/06/2023 at 23:08, Conor Dooley wrote:
> > On Sun, Jun 04, 2023 at 11:49:48AM +0200, Arnd Bergmann wrote:
> > > On Sat, Jun 3, 2023, at 23:23, Conor Dooley wrote:
> > > > On Sat, Jun 03, 2023 at 10:19:50PM +0100, Conor Dooley wrote:
> > > > > Hey Varshini,
> > > > > 
> > > > > On Sun, Jun 04, 2023 at 01:32:37AM +0530, Varshini Rajendran wrote:
> > > > > > Document the support added for the Advanced interrupt controller(AIC)
> > > > > > chip in the sam9x7 soc family
> > > > > Please do not add new family based compatibles, but rather use per-soc
> > > > > compatibles instead.
> > > > These things leave me penally confused. Afaiu, sam9x60 is a particular
> > s/penally/perennially/
> > 
> > > > SoC. sam9x7 is actually a family, containing sam9x70, sam9x72 and
> > > > sam9x75. It would appear to me that each should have its own compatible,
> > > > no?
> > > I think the usual way this works is that the sam9x7 refers to the
> > > SoC design as in what is actually part of the chip, whereas the 70,
> > > 72 and 75 models are variants that have a certain subset of the
> > > features enabled.
> 
> Yes, That's the case.
> > > If that is the case here, then referring to the on-chip parts by
> > > the sam9x7 name makes sense, and this is similar to what we do
> > > on TI AM-series chips.
> 
> This is what we did for most of our SoCs families, indeed.
> 
> > If it is the case that what differentiates them is having bits chopped
> > off, and there's no implementation differences that seems fair.
> 
> Ok, thanks.
> 
> > > There is a remaining risk that a there would be a future
> > > sam9x71/73/74/76/... product based on a new chip that uses
> > > incompatible devices, but at that point we can still use the
> > > more specific model number to identify those without being
> > > ambiguous.
> 
> This is exactly what we did for sama5d29 which is not the same silicon vs.
> the other members of the sama5d2 family. We used the more specify sama5d29
> sub-string for describing the changing parts (CAN-FD and Ethernet).
> 
> > > The same thing can of course happen when a SoC
> > > vendor reuses a specific name of a prior product with an update
> > > chip that has software visible changes.
> > > 
> > > I'd just leave this up to Varshini and the other at91 maintainers
> > > here, provided they understand the exact risks.
> 
> Yep, I understand the risk and will try to review the compatibility strings
> that would need more precise description (maybe PMC or AIC).
> 
> > Ye, seems fair to me. Nicolas/Claudiu etc, is there a convention to use
> > the "0" model as the compatible (like the 9x60 did) or have "random"
> > things been done so far?
> 
> sam9x60 was a single SoC, not a member of a "family", so there was no
> meaning of the "0" here. Moreover, the "0" ones are usually not the subset,
> if it even exists.
> So far, we used the silicon string to define the compatibility string,
> adding a more precise string for hardware of family members that needed it
> (as mentioned above for sama5d29).
> 
> > > It's different for the parts that are listed as just sam9x60
> > > compatible in the DT, I think those clearly need to have sam9x7
> > > in the compatible list, but could have the sam9x60 identifier
> > > as a fallback if the hardware is compatible.
> > Aye.
> 
> Yep, agreed.

Can we convert this binding to schema so all this is perfectly clear 
what's valid or not.

Rob