Re: clk maintenance [Was: Re: [PATCH v1] clk: Use named initializers for platform_device_id arrays]

[Brian Masney]

Hi Uwe,

On Sat, Jul 18, 2026 at 07:13:11PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> [I trimmed recipients as the new topic isn't related only to my patch
> under discussion in this thread.]
> 
> On Fri, Jul 17, 2026 at 10:57:54AM -0400, Brian Masney wrote:
> > On Fri, Jul 17, 2026 at 11:51:17AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > Do you still have it on your radar?
> > 
> > I sent Stephen a pull on June 29th for stuff that I felt was missed during
> > the last merge window and I included 4 of your patches in that pull:
> > 
> > https://lore.kernel.org/linux-clk/akLzCVzbMbUsgDda@xxxxxxxxxx/T/#u
> > 
> > I haven't heard from Stephen yet. There's 2-3 other pulls waiting as
> > well.
> 
> I only occasionally have clk patches, but my impression is that getting
> feedback takes quite long and without Brian's efforts also things would
> get lost. (Thanks Brian for picking up my stuff!)
> 
> Looking at the current maintainers:
> 
> 	$ git log --format=fuller --since 2026-01-01 next-20260717 drivers/clk | grep -E 'Boyd|Turquette' | sort | uniq -c
> 	      8     Acked-by: Stephen Boyd <sboyd@xxxxxxxxxx>
> 	     28 Author:     Stephen Boyd <sboyd@xxxxxxxxxx>
> 	      3     Cc: Michael Turquette <mturquette@xxxxxxxxxxxx>
> 	      3     Cc: Stephen Boyd <sboyd@xxxxxxxxxx>
> 	     81 Commit:     Stephen Boyd <sboyd@xxxxxxxxxx>
> 	      1     Pull clk fix from Stephen Boyd:
> 	      3     Pull clk updates from Stephen Boyd:
> 	     54     Signed-off-by: Stephen Boyd <sboyd@xxxxxxxxxx>
> 	linux$ git log --format=oneline --since 2026-01-01 next-20260717 drivers/clk | wc -l
> 	453
> 
> (Maybe that is because Stephen cares for the core mostly and arch
> maintainers merge stuff about their clks themselves?)
> 
> The last commit where Michael Turquette was actively involved is from
> 2021 (a331659e32718b31f3a304d7797a77d31610468c) which is also the last
> mail from him on the clk list (see
> https://lore.kernel.org/linux-clk/?q=f%3ATurquette).
> 
> I only observe from the side line, but with the relevance of the clk
> subsystem I feel maintenance is underpowered today.
> 
> Is it time for Michael to step down? Would Brian be ready to become a
> full maintainer? Is there a need for more reviewers? Any volunteers to
> step up?

As Chen-Yu mentioned, I talked to Stephen about this at Linux Plumbers
in person last December. I'm interested, and given the importance of the
subsystem, I think we actually need even more people to help spread the
load for a healthy ecosystem.

Since there's a fair bit of odds and ends that get missed, I tried to
start gathering things up for v7.1rc1:

https://lore.kernel.org/linux-clk/abLV9vjYxXsKciHW@xxxxxxxxxx/

But I never got a response outside of Andy's response. I don't know if
Stephen didn't like things that were in it, or if he didn't like that I
gathered up patches from other folks. I just don't know.

That's why during the next merge window I just brought missing patches
in the pull to Linus:

https://lore.kernel.org/linux-clk/aeeHSrZmAqE4ugXY@xxxxxxxxxx/

... and again during the last merge window:

https://lore.kernel.org/linux-clk/aj1NUYRrD30ctAbt@xxxxxxxxxx/

Next week I plan to post another pull for new material posted this
development cycle for things that I feel are ready, and where they won't
be sent in by someone else via a different pull.

I'm not trying to take anything from anyone, and I'm not trying to make
anyone mad. I'm just trying to step up and help make the situation in
the clk subsystem better.

I'm also trying to separately address some long-standing issues in the
framework:

    v3: clk: implement sync_state support
    https://lore.kernel.org/linux-clk/20260626-clk-sync-state-v1-0-4156d8196dc8@xxxxxxxxxx/

    v8: clk: add support for v1 / v2 clock rate negotiation and kunit tests
    https://lore.kernel.org/linux-clk/20260327-clk-scaling-v8-0-86cd0aba3c5f@xxxxxxxxxx/

I also removed the round_rate() op, which involved 200+ patches across
the tree.

To help with review, I also think that we should enable Sashiko reviews
to the mainglist like some other subsystems currently have enabled.

Brian