Re: About clk maintainership [Was: Re: [PULL] Add variants of devm_clk_get for prepared and enabled clocks enabled clocks]

[Stephen Boyd <sboyd@xxxxxxxxxx>]

Quoting Russell King (Oracle) (2021-07-28 13:40:34)
> > I adapted the Subject in the hope to catch Stephen's and Michael's
> > attention. My impression is that this thread isn't on their radar yet,
> > but the topic here seems important enough to get a matching Subject.

The thread is on my radar but...

> 
> Have you thought about sending your pull request to the clk API
> maintainer (iow, me) ?
> 

+1 This patch doesn't fall under CCF maintainer.

 $ ./scripts/get_maintainer.pl -f include/linux/clk.h
 Russell King <linux@xxxxxxxxxxxxxxx> (maintainer:CLK API)
 linux-clk@xxxxxxxxxxxxxxx (open list:CLK API)
 linux-kernel@xxxxxxxxxxxxxxx (open list)

Finally, this sort of patch has been discussed for years and I didn't
see any mention of those previous attempts in the patch series. Has
something changed since that time? I think we've got a bunch of hand
rolled devm things in the meantime but not much else. 

I still wonder if it would be better if we had some sort of DT binding
that said "turn this clk on when the driver probes this device and keep
it on until the driver is unbound". That would probably work well for
quite a few drivers that don't want to ever call clk_get() or
clk_prepare_enable() and could tie into the assigned-clock-rates
property in a way that let us keep the platform details out of the
drivers. We could also go one step further and make a clk pm domain when
this new property is present and then have the clk be enabled based on
runtime PM of the device (and if runtime PM is disabled then just enable
it at driver probe time).