lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <06e799be-b7c0-5b93-8586-678a449d2239@microchip.com>
Date:   Mon, 26 Jul 2021 09:18:16 +0000
From:   <Claudiu.Beznea@...rochip.com>
To:     <u.kleine-koenig@...gutronix.de>, <andy.shevchenko@...il.com>
CC:     <wsa@...nel.org>, <sboyd@...nel.org>, <linux-rtc@...r.kernel.org>,
        <linux-pwm@...r.kernel.org>, <alexandre.belloni@...tlin.com>,
        <a.zummo@...ertech.it>, <mturquette@...libre.com>,
        <Nicolas.Ferre@...rochip.com>, <linux-spi@...r.kernel.org>,
        <o.rempel@...gutronix.de>, <Ludovic.Desroches@...rochip.com>,
        <broonie@...nel.org>, <thierry.reding@...il.com>,
        <aardelean@...iqon.com>, <kernel@...gutronix.de>,
        <Jonathan.Cameron@...wei.com>, <akpm@...ux-foundation.org>,
        <lee.jones@...aro.org>, <linux-clk@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <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

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 <u.kleine-koenig@...gutronix.de>
> Date:
> 23.07.2021, 12:13
> 
> 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>
> 
> 
> 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?

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/ |
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ