| Message ID | 20220906135004.14885-1-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | leds: deduplicate led_init_default_state_get() | expand |
On Tue, Sep 06, 2022 at 04:49:53PM +0300, Andy Shevchenko wrote: > There are several users of LED framework that reimplement the > functionality of led_init_default_state_get(). In order to > deduplicate them move the declaration to the global header > (patch 2) and convert users (patche 3-11). Can this be applied now? Lee, Pavel, what do you think? > Changelog v3: > - added tag to patch 11 (Kurt) > - Cc'ed to Lee, who might help with LED subsystem maintenance > > Changelog v2: > - added missed patch 2 and hence make it the series > - appended tag to patch 7 > - new patch 1
On Tue, Sep 06, 2022 at 04:49:53PM +0300, Andy Shevchenko wrote: > There are several users of LED framework that reimplement the > functionality of led_init_default_state_get(). In order to > deduplicate them move the declaration to the global header > (patch 2) and convert users (patche 3-11). Dear LED maintainers, is there any news on this series? It's hanging around for almost 2 months now... > Changelog v3: > - added tag to patch 11 (Kurt) > - Cc'ed to Lee, who might help with LED subsystem maintenance > > Changelog v2: > - added missed patch 2 and hence make it the series > - appended tag to patch 7 > - new patch 1 > > Andy Shevchenko (11): > leds: add missing includes and forward declarations in leds.h > leds: Move led_init_default_state_get() to the global header > leds: an30259a: Get rid of custom led_init_default_state_get() > leds: bcm6328: Get rid of custom led_init_default_state_get() > leds: bcm6358: Get rid of custom led_init_default_state_get() > leds: mt6323: Get rid of custom led_init_default_state_get() > leds: mt6360: Get rid of custom led_init_default_state_get() > leds: pca955x: Get rid of custom led_init_default_state_get() > leds: pm8058: Get rid of custom led_init_default_state_get() > leds: syscon: Get rid of custom led_init_default_state_get() > net: dsa: hellcreek: Get rid of custom led_init_default_state_get() > > drivers/leds/flash/leds-mt6360.c | 38 +++-------------- > drivers/leds/leds-an30259a.c | 21 ++-------- > drivers/leds/leds-bcm6328.c | 49 +++++++++++----------- > drivers/leds/leds-bcm6358.c | 32 +++++++------- > drivers/leds/leds-mt6323.c | 30 ++++++------- > drivers/leds/leds-pca955x.c | 26 +++--------- > drivers/leds/leds-pm8058.c | 29 ++++++------- > drivers/leds/leds-syscon.c | 49 ++++++++++------------ > drivers/leds/leds.h | 1 - > drivers/net/dsa/hirschmann/hellcreek_ptp.c | 45 ++++++++++---------- > include/linux/leds.h | 15 ++++--- > 11 files changed, 143 insertions(+), 192 deletions(-) > > -- > 2.35.1 >
On Tue, 25 Oct 2022, Andy Shevchenko wrote: > On Tue, Sep 06, 2022 at 04:49:53PM +0300, Andy Shevchenko wrote: > > There are several users of LED framework that reimplement the > > functionality of led_init_default_state_get(). In order to > > deduplicate them move the declaration to the global header > > (patch 2) and convert users (patche 3-11). > > Dear LED maintainers, is there any news on this series? It's hanging around > for almost 2 months now... My offer still stands if help is required.
On Mon, Oct 31, 2022 at 08:53:49AM +0000, Lee Jones wrote: > On Tue, 25 Oct 2022, Andy Shevchenko wrote: > > > On Tue, Sep 06, 2022 at 04:49:53PM +0300, Andy Shevchenko wrote: > > > There are several users of LED framework that reimplement the > > > functionality of led_init_default_state_get(). In order to > > > deduplicate them move the declaration to the global header > > > (patch 2) and convert users (patche 3-11). > > > > Dear LED maintainers, is there any news on this series? It's hanging around > > for almost 2 months now... > > My offer still stands if help is required. From my point of view the LED subsystem is quite laggish lately (as shown by this patch series, for instance), which means that _in practice_ the help is needed, but I haven't got if we have any administrative agreement on that. Pavel?
On Mon, Oct 31, 2022 at 05:32:26PM +0200, Andy Shevchenko wrote: > On Mon, Oct 31, 2022 at 08:53:49AM +0000, Lee Jones wrote: > > On Tue, 25 Oct 2022, Andy Shevchenko wrote: > > > > > On Tue, Sep 06, 2022 at 04:49:53PM +0300, Andy Shevchenko wrote: > > > > There are several users of LED framework that reimplement the > > > > functionality of led_init_default_state_get(). In order to > > > > deduplicate them move the declaration to the global header > > > > (patch 2) and convert users (patche 3-11). > > > > > > Dear LED maintainers, is there any news on this series? It's hanging around > > > for almost 2 months now... > > > > My offer still stands if help is required. > > From my point of view the LED subsystem is quite laggish lately (as shown by > this patch series, for instance), which means that _in practice_ the help is > needed, but I haven't got if we have any administrative agreement on that. > > Pavel? So, Pavel seems quite unresponsive lately... Shall we just move on and take maintainership?
On Tue, 08 Nov 2022, Andy Shevchenko wrote: > On Mon, Oct 31, 2022 at 05:32:26PM +0200, Andy Shevchenko wrote: > > On Mon, Oct 31, 2022 at 08:53:49AM +0000, Lee Jones wrote: > > > On Tue, 25 Oct 2022, Andy Shevchenko wrote: > > > > > > > On Tue, Sep 06, 2022 at 04:49:53PM +0300, Andy Shevchenko wrote: > > > > > There are several users of LED framework that reimplement the > > > > > functionality of led_init_default_state_get(). In order to > > > > > deduplicate them move the declaration to the global header > > > > > (patch 2) and convert users (patche 3-11). > > > > > > > > Dear LED maintainers, is there any news on this series? It's hanging around > > > > for almost 2 months now... > > > > > > My offer still stands if help is required. > > > > From my point of view the LED subsystem is quite laggish lately (as shown by > > this patch series, for instance), which means that _in practice_ the help is > > needed, but I haven't got if we have any administrative agreement on that. > > > > Pavel? > > So, Pavel seems quite unresponsive lately... Shall we just move on and take > maintainership? I had an off-line conversation with Greg who advised me against that.
On Mon, Nov 14, 2022 at 10:11:25AM +0000, Lee Jones wrote: > On Tue, 08 Nov 2022, Andy Shevchenko wrote: > > On Mon, Oct 31, 2022 at 05:32:26PM +0200, Andy Shevchenko wrote: > > > On Mon, Oct 31, 2022 at 08:53:49AM +0000, Lee Jones wrote: > > > > On Tue, 25 Oct 2022, Andy Shevchenko wrote: > > > > > > > > > On Tue, Sep 06, 2022 at 04:49:53PM +0300, Andy Shevchenko wrote: > > > > > > There are several users of LED framework that reimplement the > > > > > > functionality of led_init_default_state_get(). In order to > > > > > > deduplicate them move the declaration to the global header > > > > > > (patch 2) and convert users (patche 3-11). > > > > > > > > > > Dear LED maintainers, is there any news on this series? It's hanging around > > > > > for almost 2 months now... > > > > > > > > My offer still stands if help is required. > > > > > > From my point of view the LED subsystem is quite laggish lately (as shown by > > > this patch series, for instance), which means that _in practice_ the help is > > > needed, but I haven't got if we have any administrative agreement on that. > > > > > > Pavel? > > > > So, Pavel seems quite unresponsive lately... Shall we just move on and take > > maintainership? > > I had an off-line conversation with Greg who advised me against that. OK. What the reasonable option we have then?
On Mon, Nov 14, 2022 at 12:19:29PM +0200, Andy Shevchenko wrote: > On Mon, Nov 14, 2022 at 10:11:25AM +0000, Lee Jones wrote: > > On Tue, 08 Nov 2022, Andy Shevchenko wrote: > > > On Mon, Oct 31, 2022 at 05:32:26PM +0200, Andy Shevchenko wrote: > > > > On Mon, Oct 31, 2022 at 08:53:49AM +0000, Lee Jones wrote: > > > > > On Tue, 25 Oct 2022, Andy Shevchenko wrote: > > > > > > > > > > > On Tue, Sep 06, 2022 at 04:49:53PM +0300, Andy Shevchenko wrote: > > > > > > > There are several users of LED framework that reimplement the > > > > > > > functionality of led_init_default_state_get(). In order to > > > > > > > deduplicate them move the declaration to the global header > > > > > > > (patch 2) and convert users (patche 3-11). > > > > > > > > > > > > Dear LED maintainers, is there any news on this series? It's hanging around > > > > > > for almost 2 months now... > > > > > > > > > > My offer still stands if help is required. > > > > > > > > From my point of view the LED subsystem is quite laggish lately (as shown by > > > > this patch series, for instance), which means that _in practice_ the help is > > > > needed, but I haven't got if we have any administrative agreement on that. > > > > > > > > Pavel? > > > > > > So, Pavel seems quite unresponsive lately... Shall we just move on and take > > > maintainership? > > > > I had an off-line conversation with Greg who advised me against that. > > OK. What the reasonable option we have then? I thought there is now a new LED maintainer, is that not working out?
On Mon, Nov 14, 2022 at 11:41:31AM +0100, Greg Kroah-Hartman wrote: > On Mon, Nov 14, 2022 at 12:19:29PM +0200, Andy Shevchenko wrote: > > On Mon, Nov 14, 2022 at 10:11:25AM +0000, Lee Jones wrote: > > > On Tue, 08 Nov 2022, Andy Shevchenko wrote: > > > > On Mon, Oct 31, 2022 at 05:32:26PM +0200, Andy Shevchenko wrote: > > > > > On Mon, Oct 31, 2022 at 08:53:49AM +0000, Lee Jones wrote: > > > > > > On Tue, 25 Oct 2022, Andy Shevchenko wrote: > > > > > > > > > > > > > On Tue, Sep 06, 2022 at 04:49:53PM +0300, Andy Shevchenko wrote: > > > > > > > > There are several users of LED framework that reimplement the > > > > > > > > functionality of led_init_default_state_get(). In order to > > > > > > > > deduplicate them move the declaration to the global header > > > > > > > > (patch 2) and convert users (patche 3-11). > > > > > > > > > > > > > > Dear LED maintainers, is there any news on this series? It's hanging around > > > > > > > for almost 2 months now... > > > > > > > > > > > > My offer still stands if help is required. > > > > > > > > > > From my point of view the LED subsystem is quite laggish lately (as shown by > > > > > this patch series, for instance), which means that _in practice_ the help is > > > > > needed, but I haven't got if we have any administrative agreement on that. > > > > > > > > > > Pavel? > > > > > > > > So, Pavel seems quite unresponsive lately... Shall we just move on and take > > > > maintainership? > > > > > > I had an off-line conversation with Greg who advised me against that. > > > > OK. What the reasonable option we have then? > > I thought there is now a new LED maintainer, is that not working out? No new (co-)maintainer due to stale mate situation as far as I can read it right now.
On Mon, Nov 14, 2022 at 01:47:58PM +0200, Andy Shevchenko wrote: > On Mon, Nov 14, 2022 at 11:41:31AM +0100, Greg Kroah-Hartman wrote: > > On Mon, Nov 14, 2022 at 12:19:29PM +0200, Andy Shevchenko wrote: > > > On Mon, Nov 14, 2022 at 10:11:25AM +0000, Lee Jones wrote: > > > > On Tue, 08 Nov 2022, Andy Shevchenko wrote: > > > > > On Mon, Oct 31, 2022 at 05:32:26PM +0200, Andy Shevchenko wrote: > > > > > > On Mon, Oct 31, 2022 at 08:53:49AM +0000, Lee Jones wrote: > > > > > > > On Tue, 25 Oct 2022, Andy Shevchenko wrote: > > > > > > > > On Tue, Sep 06, 2022 at 04:49:53PM +0300, Andy Shevchenko wrote: > > > > > > > > > There are several users of LED framework that reimplement the > > > > > > > > > functionality of led_init_default_state_get(). In order to > > > > > > > > > deduplicate them move the declaration to the global header > > > > > > > > > (patch 2) and convert users (patche 3-11). > > > > > > > > > > > > > > > > Dear LED maintainers, is there any news on this series? It's hanging around > > > > > > > > for almost 2 months now... > > > > > > > > > > > > > > My offer still stands if help is required. > > > > > > > > > > > > From my point of view the LED subsystem is quite laggish lately (as shown by > > > > > > this patch series, for instance), which means that _in practice_ the help is > > > > > > needed, but I haven't got if we have any administrative agreement on that. > > > > > > > > > > > > Pavel? > > > > > > > > > > So, Pavel seems quite unresponsive lately... Shall we just move on and take > > > > > maintainership? > > > > > > > > I had an off-line conversation with Greg who advised me against that. > > > > > > OK. What the reasonable option we have then? > > > > I thought there is now a new LED maintainer, is that not working out? > > No new (co-)maintainer due to stale mate situation as far as I can read it > right now. So, any suggestion on how to proceed here? De facto we have no patch flow in LED subsystem and the queue is growing...