Re: [PULL] Add variants of devm_clk_get for prepared and enabled clocks enabled clocks

From: Uwe Kleine-König
Date: Fri Jul 23 2021 - 05:14:15 EST


[adding Linus and lkml to Cc: and adding some more context]

On Wed, Jun 09, 2021 at 10:21:23PM +0200, Uwe Kleine-König wrote:
> given that I don't succeed in getting any feedback for my patch set, I'm
> trying with a pull request today.

This is for a series that is currently in v7 and didn't get any feedback
at all yet. The history is:

v1: 2020-10-13,
no feedback at all

v2: 2021-03-01,
kernel test robot identified some issues

v3: 2021-03-01,
I added a few driver patches to show the benefit. (However in a way
that the autobuilders don't understand, so there were some false
positive build failure reports.)

v4: 2021-03-30,
Got some feedback for the converted drivers by the respective
maintainers. Some were indifferent, some found it good

v5: 2021-04-22,
Fixed a problem in one of the driver changes (i2c-imx), no feedback
apart from pointing out a few typos, silence from the clk

v6: 2021-04-26,
Just the typos fixed, no feedback

v6 resend: 2021-05-10,
no changes in code. Got some feedback from Jonathan Cameron

v7: 2021-05-10,
Adress Jonathan's feedback, recieved some more acks from non-clk

pull request: 2021-07-09,

On Fri, Jul 23, 2021 at 11:26:58AM +0300, Andy Shevchenko wrote:
> On Thursday, July 22, 2021, Wolfram Sang <wsa@xxxxxxxxxx> wrote:
> >
> > > > What about adding gkh to the list explaining the situation to him?
> > >
> > > Greg doesn't like devm_ stuff.
> > >
> > > I already asked Arnd who doesn't want to interfere and akpm who didn't
> > > react either up to now.
> >
> > Wow, okay, that is frustrating.
> The situation simply shows the process gap and One Maintainer nowadays is
> far from enough to satisfy demands.

Technically there are two maintainers for drivers/clk, Michael Turquette
and Stephen Boyd. It seems Michael is MIA and Stephen doesn't have the
capacity to address all requests.

> What I think about is that we need to escalate this to Linus and
> others and elaborate the mechanisms how to squeeze a new (additional)
> maintainer when the original one is not responsive. Let’s say some
> procedural steps. Otherwise we doomed because of human factor.

Assuming there was some process for this, is there someone who is
willing to take responsibility here?

Best regards

Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | |

Attachment: signature.asc
Description: PGP signature