[GIT PULL 3/4] Renesas DT binding updates for v7.1

Krzysztof Kozlowski krzk at kernel.org
Tue Mar 17 02:29:50 PDT 2026


On 16/03/2026 09:51, Geert Uytterhoeven wrote:
> Hi Krzysztof,
> 
> Thanks for your comments!
> 
> On Sat, 14 Mar 2026 at 12:09, Krzysztof Kozlowski <krzk at kernel.org> wrote:
>> On Fri, Mar 13, 2026 at 12:12:59PM +0100, Geert Uytterhoeven wrote:
>>> Renesas DT binding updates for v7.1
>>>
>>>   - Document RZ/G3L SoC variants, the RZ/G3L SYSC block, and RZ/G3L
>>>     SMARC SoM and Carrier-II EVK boards.
>>>
>>> ----------------------------------------------------------------
>>> Biju Das (2):
>>>       dt-bindings: soc: renesas: Document RZ/G3L SoC variants, SMARC SoM and Carrier-II EVK
>>
>> This is DTS branch patch.
> 
> It is a DT bindings patch.

I speak about branches. You quoted submitting patches in DT, but that is
implied. I already know it, I was making changes there and I already use
that document as arguments in multiple discussion, so please assume I
know it and my comments reflect that knowledge. I actually assumed that
you also knew it.

DT binding patch should go with the patch using the binding. So DT
binding for board is clearly a DTS branch patch.

> 
>>>       dt-bindings: soc: renesas: renesas,rzg2l-sysc: Document RZ/G3L SoC
>>
>> This is drivers. Splitting it into additional branch is not making it
>> easier. I don't know where is this supposed to be merged. I will take it
>> to drivers, but in the future, please do not put DTS bindings into
>> driver bindings.
> 
> This is also a DT bindings patch.

But for which code? Driver or DTS?

> 
> DT bindings are soft dependencies for drivers and DTS.
> DT binding definitions (I don't have any this time) are hard
> dependencies for drivers, DTS, and examples and DT bindings.
> Arnd merges dt-bindings PRs in the soc DTS branch.

Then this should not be a separate branch, because:

1. No benefits - you did not solve any soft dependency. Your DTS branch
is non-bisectable from dtbs_check point of view and you as maintainer of
that tree should try to make it bisectable, meaning: "bindings go before
user" like explained in what you quoted further.

And please also read rest of submitting patches, although it is in part
for "submitters" but explains the concept:

" 5) The Documentation/ portion of the patch should come in the series
before the code implementing the binding."

"6) Any compatible strings used in a chip or board DTS file must be
previously documented in the corresponding DT binding file"

Previously means "before", so your DTS branch is failing above.

2. It is additional effort to handle this, because instead of merging
one branch, I need to merge two.

> 
>> See also submitting patches in DT dir.
> 
> So the second commit is subject to II.3:
> 
>   3) For a series going through multiple trees, the binding patch should be
>      kept with the driver using the binding.
> 
> In this particular case, I could have included it in my drivers branch.
> Where do I put SoC-specific DT binding changes that are not picked
> up by anyone else (I don't have any this time)?

What is "SoC-specific"? You put the DT binding with the user, that was
always the rule and that is implied by submitting patches. If you do not
have any user, why would you pick that up?

Best regards,
Krzysztof



More information about the linux-arm-kernel mailing list