On 23.07.2021 12:13, Uwe Kleine-König wrote:

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe


ForwardedMessage.eml

Subject:
Re: [PULL] Add variants of devm_clk_get for prepared and enabled clocks
enabled clocks
From:
Uwe Kleine-König [off-list ref]
Date:
23.07.2021, 12:13

To:
Andy Shevchenko [off-list ref]
CC:
Wolfram Sang [off-list ref], Stephen Boyd [off-list ref],
"linux-rtc@vger.kernel.org" [off-list ref],
"linux-pwm@vger.kernel.org" [off-list ref], Alexandre Belloni
[off-list ref], Claudiu Beznea
[off-list ref], Alessandro Zummo [off-list ref],
Michael Turquette [off-list ref], Nicolas Ferre
[off-list ref], "linux-spi@vger.kernel.org"
[off-list ref], Oleksij Rempel [off-list ref],
Ludovic Desroches [off-list ref], Mark Brown
[off-list ref], Thierry Reding [off-list ref], Alexandru
Ardelean [off-list ref], "kernel@pengutronix.de"
[off-list ref], Jonathan Cameron [off-list ref],
Andrew Morton [off-list ref], Lee Jones
[off-list ref], "linux-clk@vger.kernel.org"
[off-list ref], "linux-arm-kernel@lists.infradead.org"
[off-list ref], Linus Torvalds
[off-list ref], [off-list ref]


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:

quoted

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 (local)
    no feedback at all

v2: 2021-03-01, https://lore.kernel.org/linux-clk/20210301110821.1445756-1-uwe@kleine-koenig.org (local)
    kernel test robot identified some issues

v3: 2021-03-01, https://lore.kernel.org/linux-clk/20210301135053.1462168-1-u.kleine-koenig@pengutronix.de (local)
    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 (local)
    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 (local)
    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 (local)
    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 (local)
    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 (local)
    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 (local)

On Fri, Jul 23, 2021 at 11:26:58AM +0300, Andy Shevchenko wrote:

quoted

On Thursday, July 22, 2021, Wolfram Sang [off-list ref] wrote:

quoted

quoted

quoted

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.

quoted

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?

Hi,

In the last year I worked on AT91 clock drivers and I would be available
for taking responsibility beyond AT91 clocks (if everyone's OK with this),
in whatever form the current maintainers and people in the audience would
agree, if any (co-maintainer or other forms that could be useful). The idea
is to help things progress as I also have patches waiting for feedback on
clock mailing list for almost 6 months.

Let me know if I can be helpful.

Thank you,
Claudiu Beznea

Best regards
Uwe
 
-- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions |
https://www.pengutronix.de/ |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel