Re: [GIT PULL] Allwinner DT Changes for 7.2
Chen-Yu Tsai <[email protected]> Tue, 9 Jun 2026 21:38:42 +0900
| Newsgroups | dev.linux.lists.soc,dev.linux.lists.linux-sunxi,org.infradead.lists.linux-arm-kernel |
|---|---|
| Message-ID | <CAGb2v64o+tgnLqK_xDoauB4ThF_0979_5XPB38KiZHYyh1BnVQ@mail.gmail.com> |
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. Would it help if Stephen gave an ack? ChenYu