From: "Arnd Bergmann" <arnd@arndb.de>
To: "Krzysztof Kozlowski" <krzk@kernel.org>,
"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 <linux-renesas-soc@vger.kernel.org>
Subject: Re: [GIT PULL 3/4] Renesas DT binding updates for v7.1
Date: Wed, 18 Mar 2026 13:58:28 +0100 [thread overview]
Message-ID: <a4174f08-cb01-4338-9909-e2d4cfd60934@app.fastmail.com> (raw)
In-Reply-To: <69927bd8-d476-4a24-91af-f21cdc0bce80@kernel.org>
On Tue, Mar 17, 2026, at 10:53, Krzysztof Kozlowski wrote:
> On 17/03/2026 10:29, Krzysztof Kozlowski wrote:
>>>> 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?
>
> Actually I want to correct myself or explain more. If you document ABI
> for existing driver with DTS user of the ABI, but without driver change,
> e.g. new front compatible when using already documented fallback, I
> would keep the change in the driver branch, even though technically the
> DTS is the user of new compatible. That is what I was always doing at least.
>
> Why? Because I expect there might be a next patchset with binding+driver
> adding new fallback to the same binding, which would have to go via
> driver branch because of mentioned submitting patches rule. Therefore if
> I put that first binding in DTS branch and in the future I want to put
> next change in the driver branch I would have unnecessary conflicts.
Right, this makes sense, though I've been rather relaxed about binding
updates in the past, merging them either through the soc/drivers
branches if they came with the driver changes, or through the soc/dt
branch otherwise.
Arnd
next prev parent reply other threads:[~2026-03-18 12:58 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
2026-03-17 9:53 ` Krzysztof Kozlowski
2026-03-18 12:58 ` Arnd Bergmann [this message]
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=a4174f08-cb01-4338-9909-e2d4cfd60934@app.fastmail.com \
--to=arnd@arndb.de \
--cc=geert@linux-m68k.org \
--cc=krzk@kernel.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