Re: [PATCH 21/37] dt-bindings: clock: add r9a08g045 CPG clocks and resets definitions
From: Krzysztof Kozlowski <hidden>
Date: 2023-09-15 07:42:51
Also in:
linux-clk, linux-devicetree, linux-gpio, linux-mmc, linux-renesas-soc, linux-serial, lkml
On 15/09/2023 09:38, Geert Uytterhoeven wrote:
Hi Krzysztof, On Fri, Sep 15, 2023 at 9:24 AM Krzysztof Kozlowski [off-list ref] wrote:quoted
On 14/09/2023 17:26, Geert Uytterhoeven wrote:quoted
On Tue, Sep 12, 2023 at 6:03 PM Rob Herring [off-list ref] wrote:quoted
On Tue, Sep 12, 2023 at 07:51:41AM +0300, Claudiu wrote:quoted
From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel