[GIT PULL] Immutable tag between SpacemiT's reset and clock trees for v6.17

[Yixun Lan]

Hi Philipp,

On 11:46 Mon 07 Jul     , Philipp Zabel wrote:
> On So, 2025-07-06 at 04:06 +0000, Yixun Lan wrote:
> > Hi Philipp,
> > 
> > On 12:02 Fri 04 Jul     , Philipp Zabel wrote:
> > > On Do, 2025-07-03 at 15:18 +0000, Yixun Lan wrote:
> > > > Hi Philipp,
> > > > 
> > > > Please pull the following change into the reset tree. This
> > > > allows you to apply the patch 5 of the SpacemiT reset driver [1].
> > > > 
> > > > Thanks,
> > > > Yixun Lan
> > > > 
> > > > Link: https://lore.kernel.org/r/20250702113709.291748-6-elder@riscstar.com [1]
> > > 
> > > Sorry I didn't notice before, this is missing k1-syscon.h from Patch 2.
> > >  
> > no problem
> > 
> > > Can we get a clock maintainer ack to place patch 2 in the shared tag as
> > > well? Otherwise you could split patch 2 into soc and clk parts.
> > for the ack, I'd assume Stephen have no objection (Cc him explicitly)
> > 
> > technically, there is no problem to place more patches in the shared
> > tag, since the tag will be both sent(by me) to clock and reset tree,
> > so no conflicts in the end.
> > 
> > if you expect to at least pass compiling test with patch 5 in reset
> > branch only, then patch 1, 2, 3 should be included, otherwise need to
> > pull clk branch for additional dependency patches.
> 
> 3 as well? Oh, that's for struct spacemit_ccu_adev. IMHO this patch
> series is not well structured for applying across trees. This should
> have been a single patch that adds include/soc/spacemit/k1-syscon.h, to
> be shared by both clk and reset trees, and no other dependencies
> between clk and reset patches for this to work well.

I feel this is much difficult, e.g. the patch 2 touches both drivers/clk
and include/soc/spacemit/k1-syscon.h - moving definitions, and splitting
into two patches sounds weird

> 
> > I would propose to have shared tag to include patch 1-4, then you can
> > pick patch 5, in this way, it should both pass all tests (both
> > compile-time and run-time)would would 
> 
> Since this is a new driver, passing run-time tests is not a concern.
> Compile-time is, since that would break bisectability for everyone.
> 
make sense

> > what do you think?
> 
> I feel like it's easier and safer for the whole series to be merged via
> the clk tree. Since this adds a new reset driver, the only possible
> merge conflicts are trivial ones in drivers/reset/{Kconfig,Makefile}.
> 
ok, I agree, then let's route the whole series via clk tree, and I assume 
Stephen is fine with this, since it's indeed much simple.

thanks

-- 
Yixun Lan (dlan)