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

[Nicolas Ferre <nicolas.ferre@microchip.com>]

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