[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210723091331.wl33wtcvvnejuhau@pengutronix.de>
Date: Fri, 23 Jul 2021 11:13:31 +0200
From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Wolfram Sang <wsa@...nel.org>, Stephen Boyd <sboyd@...nel.org>,
"linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
"linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Claudiu Beznea <claudiu.beznea@...rochip.com>,
Alessandro Zummo <a.zummo@...ertech.it>,
Michael Turquette <mturquette@...libre.com>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
Oleksij Rempel <o.rempel@...gutronix.de>,
Ludovic Desroches <ludovic.desroches@...rochip.com>,
Mark Brown <broonie@...nel.org>,
Thierry Reding <thierry.reding@...il.com>,
Alexandru Ardelean <aardelean@...iqon.com>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Lee Jones <lee.jones@...aro.org>,
"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PULL] Add variants of devm_clk_get for prepared and enabled
clocks enabled clocks
Hello,
[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, https://lore.kernel.org/linux-clk/20201013082132.661993-1-u.kleine-koenig@pengutronix.de
no feedback at all
v2: 2021-03-01, https://lore.kernel.org/linux-clk/20210301110821.1445756-1-uwe@kleine-koenig.org
kernel test robot identified some issues
v3: 2021-03-01, https://lore.kernel.org/linux-clk/20210301135053.1462168-1-u.kleine-koenig@pengutronix.de
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, https://lore.kernel.org/linux-clk/20210330181755.204339-1-u.kleine-koenig@pengutronix.de
Got some feedback for the converted drivers by the respective
maintainers. Some were indifferent, some found it good
v5: 2021-04-22, https://lore.kernel.org/linux-clk/20210422065726.1646742-1-u.kleine-koenig@pengutronix.de
Fixed a problem in one of the driver changes (i2c-imx), no feedback
apart from pointing out a few typos, silence from the clk
maintainers
v6: 2021-04-26, https://lore.kernel.org/linux-clk/20210426141730.2826832-1-u.kleine-koenig@pengutronix.de
Just the typos fixed, no feedback
v6 resend: 2021-05-10, https://lore.kernel.org/linux-clk/20210510061724.940447-1-u.kleine-koenig@pengutronix.de
no changes in code. Got some feedback from Jonathan Cameron
v7: 2021-05-10, https://lore.kernel.org/linux-clk/20210510174142.986250-1-u.kleine-koenig@pengutronix.de
Adress Jonathan's feedback, recieved some more acks from non-clk
people
pull request: 2021-07-09, https://lore.kernel.org/linux-clk/20210609202123.u5rmw7al4x3rrvun@pengutronix.de
On Fri, Jul 23, 2021 at 11:26:58AM +0300, Andy Shevchenko wrote:
> On Thursday, July 22, 2021, Wolfram Sang <wsa@...nel.org> 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
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists