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

Arnd Bergmann arnd at arndb.de
Wed Mar 18 05:58:28 PDT 2026


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



More information about the linux-arm-kernel mailing list