On 15/09/2023 09:38, Geert Uytterhoeven wrote: > Hi Krzysztof, > > On Fri, Sep 15, 2023 at 9:24 AM Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> wrote: >> On 14/09/2023 17:26, Geert Uytterhoeven wrote: >>> On Tue, Sep 12, 2023 at 6:03 PM Rob Herring <robh@xxxxxxxxxx> wrote: >>>> On Tue, Sep 12, 2023 at 07:51:41AM +0300, Claudiu wrote: >>>>> From: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx> >>>>> >>>>> Add RZ/G3S (R9A08G045) Clock Pulse Generator (CPG) core clocks, module >>>>> clocks and resets. >>>> >>>> This is part of the binding, so it can be squashed with the previous >>>> patch. The ack there still stands. >>> >>> Usually we keep it as a separate patch, to be queued in an immutable >>> branch, as it is included by both the clock driver and by DTS, but >>> not by the yaml bindings file. >> >> Binding also should be shared, so you get compatible documented in both >> places (thus lack of checkpatch warnings). It still should be one patch. > > Hmm, I see your point... > > For core Renesas SoCs components where I am (sub)maintainer for both > the driver subsystem and the DTS, I can take care of that. > For the generic case, that will need a lot of cooperation with subsystem > maintainers, to create lots of small immutable branches with DT bindings > and DT binding definition updates. Wait, I think I was too vague. "Binding also should be shared..." s/should/can/ I did not want to say that every time bindings should be shared, but rather that if already sharing the headers, you can share the bindings and you will get benefits - happy checkpatch in both places. > > Alternatively, are you (the DT maintainers) prepared to handle all > DT bindings and DT binding definition updates, and create immutable > branches for all of them (in a timely manner, of course)? > Then we can start enforcing the rule that driver and DTS updates must > not cause checkpatch warnings for missing compatible values, and must > not be applied without merging the corresponding immutable branch first. I don't think we are ready for any of this, but it is just my incorrect English or too fast typing before :) Best regards, Krzysztof
