[GIT PULL] Allwinner DT Changes for 7.2

[Krzysztof Kozlowski]

On 09/06/2026 14:38, Chen-Yu Tsai wrote:
> On Tue, Jun 9, 2026 at 8:51 PM Krzysztof Kozlowski <krzk at kernel.org> wrote:
>>
>> On 09/06/2026 13:48, Chen-Yu Tsai wrote:
>>> On Tue, Jun 9, 2026 at 8:43 PM Krzysztof Kozlowski <krzk at kernel.org> wrote:
>>>>
>>>> On Tue, Jun 02, 2026 at 03:09:52AM +0800, Chen-Yu Tsai wrote:
>>>>> The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
>>>>>
>>>>>   Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
>>>>>
>>>>> are available in the Git repository at:
>>>>>
>>>>>   https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-dt-for-7.2
>>>>>
>>>>> for you to fetch changes up to 44cf19e41c769720750dbb8752aca75c247e565f:
>>>>>
>>>>>   arm64: dts: allwinner: a523: add gpadc node (2026-05-25 05:02:58 +0800)
>>>>>
>>>>>
>>>>> As mentioned in the tag, this pull request contains a change that should
>>>>> be shared between the soc and clk trees. However since I don't have any
>>>>> clk changes to send this cycle, I think it can just go through the soc
>>>>> tree without any issues.
>>>>
>>>> But the clock driver change cannot be in the DTS branch. This should go
>>>> via clock tree even if it is one change. And definitely not via DTS
>>>> branch.
>>>
>>> It is a shared change, because it moves two symbols from the driver's
>>> private header to the public DT binding header. I don't see how this
>>> can go through just the clk tree when one of the subsequent patches
>>> uses those new symbols.
>>>
>>> "clk: sunxi-ng: v3s: Export MBUS and DRAM clocks to the public header"
>>> is needed by "ARM: dts: sun8i: v3s: Add mbus node to represent the
>>> interconnect".
>>>
>>> The other way to go about this is to use raw numbers first, then
>>> another patch in the next cycle to switch the numbers to actual
>>> macros. IMHO not worth the churn and headache.
>>
>> You can have a duplicated define.
> 
> I honestly did not know that it worked.
> 
> However, splitting what is effectively one logical change (*move*
> something) into two patches just to be able to merge them through two
> separate trees still seems wrong to me.

It is not really one logical change. Defining a new ABI (binding header
define) is considered one change. Merging binding change into driver
commit breaks rule of splitting bindings from implementation.

Second rule is that DTS branch CANNOT take driver changes. So if you do
not want to adhere to the above rule you still cannot combine it into
DTS branch.

Best regards,
Krzysztof