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@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. 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
