From: Krzysztof Kozlowski <krzk@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: soc@lists.linux.dev, Magnus Damm <magnus.damm@gmail.com>,
linux-arm-kernel@lists.infradead.org,
linux-renesas-soc@vger.kernel.org
Subject: Re: [GIT PULL 3/4] Renesas DT binding updates for v7.1
Date: Tue, 17 Mar 2026 10:29:50 +0100 [thread overview]
Message-ID: <bdefa3d7-353c-4aa1-a013-685b46773fe7@kernel.org> (raw)
In-Reply-To: <CAMuHMdXJx14SDXq7oQ-m-576GRQztRybs1HSinzf03ttvF3c_g@mail.gmail.com>
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@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
next prev parent reply other threads:[~2026-03-17 9:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 11:12 [GIT PULL 0/4] Renesas SoC updates for v7.1 Geert Uytterhoeven
2026-03-13 11:12 ` [GIT PULL 1/4] Renesas ARM defconfig " Geert Uytterhoeven
2026-03-13 11:12 ` [GIT PULL 2/4] Renesas driver " Geert Uytterhoeven
2026-03-13 11:12 ` [GIT PULL 3/4] Renesas DT binding " Geert Uytterhoeven
2026-03-14 11:09 ` Krzysztof Kozlowski
2026-03-16 8:51 ` Geert Uytterhoeven
2026-03-17 9:29 ` Krzysztof Kozlowski [this message]
2026-03-17 9:53 ` Krzysztof Kozlowski
2026-03-18 12:58 ` Arnd Bergmann
2026-03-13 11:13 ` [GIT PULL 4/4] Renesas DTS " Geert Uytterhoeven
2026-03-14 11:13 ` Krzysztof Kozlowski
2026-03-16 8:15 ` Geert Uytterhoeven
2026-03-14 11:23 ` Krzysztof Kozlowski
2026-03-16 8:18 ` Geert Uytterhoeven
2026-03-16 8:22 ` Krzysztof Kozlowski
2026-03-16 8:25 ` Geert Uytterhoeven
2026-03-17 8:32 ` [GIT PULL 0/4] Renesas SoC " Krzysztof Kozlowski
2026-03-17 8:46 ` Geert Uytterhoeven
2026-03-17 9:11 ` Krzysztof Kozlowski
2026-03-18 12:56 ` Arnd Bergmann
2026-03-18 13:12 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bdefa3d7-353c-4aa1-a013-685b46773fe7@kernel.org \
--to=krzk@kernel.org \
--cc=geert@linux-m68k.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=soc@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox