[PATCH] dt-bindings: ARM: at91: Document Microchip SAMA7D65 Curiosity

[PATCH] dt-bindings: ARM: at91: Document Microchip SAMA7D65 Curiosity

[Dharma Balasubiramani]

From: Romain Sioen <romain.sioen@microchip.com>

Document device tree binding of the Microchip SAMA7D65 Curiosity board.

Signed-off-by: Romain Sioen <romain.sioen@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
---
 Documentation/devicetree/bindings/arm/atmel-at91.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
index 82f37328cc69..8e897680d43a 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
@@ -174,6 +174,13 @@ properties:
           - const: atmel,sama5d4
           - const: atmel,sama5
 
+      - description: Microchip SAMA7D65 Curiosity Board
+        items:
+          - const: microchip,sama7d65-curiosity
+          - const: microchip,sama7d65
+          - const: microchip,sama7d6
+          - const: microchip,sama7
+
       - items:
           - const: microchip,sama7g5ek # SAMA7G5 Evaluation Kit
           - const: microchip,sama7g5

---
base-commit: b18bbfc14a38b5234e09c2adcf713e38063a7e6e
change-id: 20240829-sama7d65-core-dt-11843832c278

Best regards,
-- 
Dharma Balasubiramani <dharma.b@microchip.com>

Re: [PATCH] dt-bindings: ARM: at91: Document Microchip SAMA7D65 Curiosity

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

On Thu, Aug 29, 2024 at 03:27:42PM +0530, Dharma Balasubiramani wrote:
> From: Romain Sioen <romain.sioen@microchip.com>
> 
> Document device tree binding of the Microchip SAMA7D65 Curiosity board.
> 
> Signed-off-by: Romain Sioen <romain.sioen@microchip.com>
> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] dt-bindings: ARM: at91: Document Microchip SAMA7D65 Curiosity

[Krzysztof Kozlowski]

On 29/08/2024 11:57, Dharma Balasubiramani wrote:
> From: Romain Sioen <romain.sioen@microchip.com>
> 
> Document device tree binding of the Microchip SAMA7D65 Curiosity board.
> 
> Signed-off-by: Romain Sioen <romain.sioen@microchip.com>
> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
> ---
>  Documentation/devicetree/bindings/arm/atmel-at91.yaml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
> index 82f37328cc69..8e897680d43a 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml
> +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
> @@ -174,6 +174,13 @@ properties:
>            - const: atmel,sama5d4
>            - const: atmel,sama5
>  
> +      - description: Microchip SAMA7D65 Curiosity Board
> +        items:
> +          - const: microchip,sama7d65-curiosity
> +          - const: microchip,sama7d65
> +          - const: microchip,sama7d6
> +          - const: microchip,sama7
> +

No. This must go with the DTS.

It's second patch you sent entirely split from the rest. That's not how
upstreaming of DTS and drivers work.

Best regards,
Krzysztof

Re: [PATCH] dt-bindings: ARM: at91: Document Microchip SAMA7D65 Curiosity

[Nicolas Ferre]

On 31/08/2024 at 15:38, Krzysztof Kozlowski wrote:
> On 29/08/2024 11:57, Dharma Balasubiramani wrote:
>> From: Romain Sioen <romain.sioen@microchip.com>
>>
>> Document device tree binding of the Microchip SAMA7D65 Curiosity board.
>>
>> Signed-off-by: Romain Sioen <romain.sioen@microchip.com>
>> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
>> Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
>> ---
>>   Documentation/devicetree/bindings/arm/atmel-at91.yaml | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
>> index 82f37328cc69..8e897680d43a 100644
>> --- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml
>> +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
>> @@ -174,6 +174,13 @@ properties:
>>             - const: atmel,sama5d4
>>             - const: atmel,sama5
>>
>> +      - description: Microchip SAMA7D65 Curiosity Board
>> +        items:
>> +          - const: microchip,sama7d65-curiosity
>> +          - const: microchip,sama7d65
>> +          - const: microchip,sama7d6
>> +          - const: microchip,sama7
>> +
> 
> No. This must go with the DTS.
> 
> It's second patch you sent entirely split from the rest. That's not how
> upstreaming of DTS and drivers work.

Krzystof,

We have been upstreaming sam9x75 SoC and now are trying with sama7d65 
SoC using a different approach.

It was mentioned to us to reduce the number of patches sent in a series, 
convert the remaining DT bindings from txt to yaml (we had quite a few), 
avoid generating new errors from the DT bot when sending new .dtsi/dts 
files... So we're trying to comply to these (valid) requirements... But 
well, it's not easy and I would like to emphasize that we are doing our 
best to address most of the (sometimes contradictory) challenges.

So now, we're trying to be very minimal in what we're sending. Address 
peripherals incrementally with trying to generate as few DT check errors 
as possible. Trying this, we're facing chicken and eggs problems: How to 
comply to a binding that is not yet accepted? How to organize 
introduction of a new SoC with a limited number of patch in a series? 
How to convert bindings to yaml and still be able to add new SoCs?

Be sure that we have been coordinating internally to be ready and send 
these patch series together. We're a team and are splitting the 
workload, I believe that it should be possible.
I feel that upstreaming a SoC is becoming overly difficult, and I added 
quite a few to Mainline throughout the years.

Can you please let us post this minimal set of patch series, give you 
the needed information and cross-reference links, but also understand 
that we're adding pieces of a big puzzle that would require a bit of 
flexibility?

Thanks for your understanding. Best regards,
   Nicolas

Re: [PATCH] dt-bindings: ARM: at91: Document Microchip SAMA7D65 Curiosity

[Krzysztof Kozlowski]

On 02/09/2024 17:10, Nicolas Ferre wrote:
> On 31/08/2024 at 15:38, Krzysztof Kozlowski wrote:
>> On 29/08/2024 11:57, Dharma Balasubiramani wrote:
>>> From: Romain Sioen <romain.sioen@microchip.com>
>>>
>>> Document device tree binding of the Microchip SAMA7D65 Curiosity board.
>>>
>>> Signed-off-by: Romain Sioen <romain.sioen@microchip.com>
>>> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
>>> Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
>>> ---
>>>   Documentation/devicetree/bindings/arm/atmel-at91.yaml | 7 +++++++
>>>   1 file changed, 7 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
>>> index 82f37328cc69..8e897680d43a 100644
>>> --- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml
>>> +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml
>>> @@ -174,6 +174,13 @@ properties:
>>>             - const: atmel,sama5d4
>>>             - const: atmel,sama5
>>>
>>> +      - description: Microchip SAMA7D65 Curiosity Board
>>> +        items:
>>> +          - const: microchip,sama7d65-curiosity
>>> +          - const: microchip,sama7d65
>>> +          - const: microchip,sama7d6
>>> +          - const: microchip,sama7
>>> +
>>
>> No. This must go with the DTS.
>>
>> It's second patch you sent entirely split from the rest. That's not how
>> upstreaming of DTS and drivers work.
> 
> Krzystof,
> 
> We have been upstreaming sam9x75 SoC and now are trying with sama7d65 
> SoC using a different approach.
> 
> It was mentioned to us to reduce the number of patches sent in a series, 
> convert the remaining DT bindings from txt to yaml (we had quite a few), 
> avoid generating new errors from the DT bot when sending new .dtsi/dts 
> files... So we're trying to comply to these (valid) requirements... But 
> well, it's not easy and I would like to emphasize that we are doing our 
> best to address most of the (sometimes contradictory) challenges.

I understand.

> 
> So now, we're trying to be very minimal in what we're sending. Address 
> peripherals incrementally with trying to generate as few DT check errors 
> as possible. Trying this, we're facing chicken and eggs problems: How to 

That's fine.

> comply to a binding that is not yet accepted? How to organize 
> introduction of a new SoC with a limited number of patch in a series? 
> How to convert bindings to yaml and still be able to add new SoCs?

Before I answer to above, let me just clarify that patch here is not
related to this problem. You are not converting bindings here, you are
not fixing dtbs_check errors.

At least as far as I understood.

This is binding for new board (new DTS). All of such bindings should
come with the board DTS. Especially that they will physically go via
same branch of maintainer's tree. That's why combing this bindings patch
with DTS patch does not result in any new warning.

Now if you ask about organizing patches, then guideline from me:
1. Send device bindings with device driver changes to respective
maintainers. Each is separate patchset.
2. Another patchset: Send bindings going through SoC maintainer with new
DTSI and DTS. Provide link lore link to the bindings, if feasible.

> Be sure that we have been coordinating internally to be ready and send 
> these patch series together. We're a team and are splitting the 
> workload, I believe that it should be possible.
> I feel that upstreaming a SoC is becoming overly difficult, and I added 
> quite a few to Mainline throughout the years.
> 
> Can you please let us post this minimal set of patch series, give you 
> the needed information and cross-reference links, but also understand 
> that we're adding pieces of a big puzzle that would require a bit of 
> flexibility?

Sure, I am flexible here. But you posted:
1. Device bindings separate from the drivers, which is just wrong and it
does not bring you anywhere. It only creates confusion and additional
effort for maintainers, because they need to review separate bindings
from drivers.

2. DTS board bindings without DTS. There is no single explanation for
this, no benefit, no reason to do that way.

Best regards,
Krzysztof