On 31/08/2024 at 15:38, Krzysztof Kozlowski wrote:
On 29/08/2024 11:57, Dharma Balasubiramani wrote:
From: Romain Sioen <romain.sioen@xxxxxxxxxxxxx>
Document device tree binding of the Microchip SAMA7D65 Curiosity board.
Signed-off-by: Romain Sioen <romain.sioen@xxxxxxxxxxxxx>
Acked-by: Nicolas Ferre <nicolas.ferre@xxxxxxxxxxxxx>
Signed-off-by: Dharma Balasubiramani <dharma.b@xxxxxxxxxxxxx>
---
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
