Re: [GIT PULL] Allwinner DT Changes for 7.2

Paul Kocialkowski <[email protected]> Tue, 9 Jun 2026 15:46:39 +0200
Newsgroups dev.linux.lists.soc,dev.linux.lists.linux-sunxi,org.infradead.lists.linux-arm-kernel
Message-ID <aigZP9W6AWzde2qo@collins>
Hi,

Le Tue 09 Jun 26, 22:26, Chen-Yu Tsai a écrit :
> On Tue, Jun 9, 2026 at 10:18 PM Krzysztof Kozlowski <[email protected]> wrote:
> >
> > On 09/06/2026 14:38, Chen-Yu Tsai wrote:
> > > On Tue, Jun 9, 2026 at 8:51 PM Krzysztof Kozlowski <[email protected]> wrote:
> > >>
> > >> On 09/06/2026 13:48, Chen-Yu Tsai wrote:
> > >>> On Tue, Jun 9, 2026 at 8:43 PM Krzysztof Kozlowski <[email protected]> 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.
> 
> Very well. I will drop the two changes and send a revised pull request.
> 
> Paul, can you redo the clk changes as requested in the next cycle?

Sure, so if I understand correctly, commit:
clk: sunxi-ng: v3s: Export MBUS and DRAM clocks to the public headersunxi

should be split into two, one adding the definitions to the dt-bindings
headers first and a second one removing them from the clk driver?

Can it still make it for 7.2?

All the best,

Paul

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEAbcMXZQMtj1fphLChP3B6o/ulQwFAmooGT8ACgkQhP3B6o/u
lQze5hAAh4nb0JtdBQTcb6rqE0JuYghcRY3WgOq9a+D58szlF96Vmt8kVC41vjXe
lH6Q3THbnM6nemQW/N6z6Nj8cZerQ6lgZF8d6MkjGIbvvrHzazajOY2BiAWYqurz
g87lGjeYnIoqMrwM2c6uAbJL59QqPSvYBUVHhNuthh8dq57NvToZ4rHGOd+1qU6X
Fc8IyiduL1p11BKAGiFxSsAaeauvwU/YDViT5GU5qAeLaxR3vud7N/PaGqlyNfsz
7NaCEpMUFZ1jZRGXebVkc680JjDWgjNwiF2gGN1pM5DXqPiKD8EB394ylb1lgZ44
+Iw9rAJpdgwgCvZ1MhBxHDbyrnIptkn6WpYGn5DEFhlwiuHztCEfgSgE6M34mzv0
jNn5+4iHAe8ewEH5FJXqy7xgFtbnKEcJLPUOW3MXe6hG9UyEBKZFqyl8bk6rPVPU
9TVKH3NsseD3m0KnZsL5j/Ljs0ySTWU5pm2cvy/+sy0vckIzkJT5z1RAMOauTyj/
bXceU2ZgcNm8e4pJ7fz6np7RrSDsDF53Jn2mPWFIUr/CLP9B4t4GuHiQE0yUsChf
SejY/kPJx2/Hpg2gwuIhuYwHw8NUZ+khe0rxstVqV7rBJVcK5YZU7JM3WKwrrEzh
4KcHRtdA9x+UFc2/w7PycdePOH695+fZ5neoLHiR77A0r8c7nII=
=+eke
-----END PGP SIGNATURE-----