LED subsystem lagging maintenance

LED subsystem lagging maintenance

[Andy Shevchenko]

Hi!

I have noticed that in the last couple of cycles the LED subsystem is
a bit laggish in terms of maintenance (*). I think it's time that
someone can help Pavel to sort things out.

In any case, I wonder if we have any kind of procedure for what to do
in such cases. Do we need to assume that the subsystem is in a
(pre-)orphaned state? If so, who is the best to take care of patch
flow?

*) e.g. I have a series against a few drivers in LED with actual fixes
and it is missed v5.13 (okay, that time Pavel had comments which I
have addressed at ~rc7 time frame), missed v5.14 and seems on the
curve to miss v5.15.

P.S. I Cc'ed lately active, AFAICS, in that area people + Greg for his opinion.

-- 
With Best Regards,
Andy Shevchenko

Re: LED subsystem lagging maintenance

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

Hi!

> I have noticed that in the last couple of cycles the LED subsystem is
> a bit laggish in terms of maintenance (*). I think it's time that
> someone can help Pavel to sort things out.
> 
> In any case, I wonder if we have any kind of procedure for what to do
> in such cases. Do we need to assume that the subsystem is in a
> (pre-)orphaned state? If so, who is the best to take care of patch
> flow?

To be honest, patches were not applied because they were not that
important to begin with, because of lacking explanation, and because
you pushed a bit too hard.

Yes, I'm quite busy in -rc1 to -rc3 timeframe with stable reviews. No,
LED subsystem is not orphaned.

Best regards,

								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: LED subsystem lagging maintenance

[Greg Kroah-Hartman]

On Wed, Jul 28, 2021 at 01:26:20PM +0300, Andy Shevchenko wrote:
> Hi!
> 
> I have noticed that in the last couple of cycles the LED subsystem is
> a bit laggish in terms of maintenance (*). I think it's time that
> someone can help Pavel to sort things out.
> 
> In any case, I wonder if we have any kind of procedure for what to do
> in such cases. Do we need to assume that the subsystem is in a
> (pre-)orphaned state? If so, who is the best to take care of patch
> flow?

What outstanding patches have not been handled?  Have you talked to
Pavel about this?

> *) e.g. I have a series against a few drivers in LED with actual fixes
> and it is missed v5.13 (okay, that time Pavel had comments which I
> have addressed at ~rc7 time frame), missed v5.14 and seems on the
> curve to miss v5.15.

If you address something at -rc7 you should not expect the changes to be
merged in time for the next release, what would you do if you were on
the other end?

> P.S. I Cc'ed lately active, AFAICS, in that area people + Greg for his opinion.

I think that Pavel should be the one asking for help here if he needs
it.

greg k-h

Re: LED subsystem lagging maintenance

[Hans de Goede]

Hi,

On 7/28/21 12:35 PM, Pavel Machek wrote:
> Hi!
> 
>> I have noticed that in the last couple of cycles the LED subsystem is
>> a bit laggish in terms of maintenance (*). I think it's time that
>> someone can help Pavel to sort things out.
>>
>> In any case, I wonder if we have any kind of procedure for what to do
>> in such cases. Do we need to assume that the subsystem is in a
>> (pre-)orphaned state? If so, who is the best to take care of patch
>> flow?
> 
> To be honest, patches were not applied because they were not that
> important to begin with, because of lacking explanation, and because
> you pushed a bit too hard.
> 
> Yes, I'm quite busy in -rc1 to -rc3 timeframe with stable reviews. No,
> LED subsystem is not orphaned.

It is good to hear that you are still actively maintaining the LED
subsystem, thank you.

This thread does remind me that I was planning on re-sending this
LED patch which seems to have fallen through the cracks:

https://lore.kernel.org/alsa-devel/20210221115208.105203-1-hdegoede@redhat.com/

Can you pick this one up please? Or shall I resend it?

Regards,

Hans

Re: LED subsystem lagging maintenance

[Andy Shevchenko]

On Wed, Jul 28, 2021 at 1:35 PM Pavel Machek <pavel@ucw.cz> wrote:

Thanks for your _prompt_ response!

> > I have noticed that in the last couple of cycles the LED subsystem is
> > a bit laggish in terms of maintenance (*). I think it's time that
> > someone can help Pavel to sort things out.
> >
> > In any case, I wonder if we have any kind of procedure for what to do
> > in such cases. Do we need to assume that the subsystem is in a
> > (pre-)orphaned state? If so, who is the best to take care of patch
> > flow?

> To be honest, patches were not applied because they were not that
> important to begin with,

Reference counting disbalance is not critical, but what is then?

> because of lacking explanation,

According to the thread
https://lore.kernel.org/linux-leds/20210529111935.3849707-1-andy.shevchenko@gmail.com/T/#u
you haven't commented a word on them. Can you, please, elaborate?

> and because
> you pushed a bit too hard.

Huh?!
It was two month and nothing from you. Good that this thread does
something about it.

> Yes, I'm quite busy in -rc1 to -rc3 timeframe with stable reviews. No,
> LED subsystem is not orphaned.

Thank you!

-- 
With Best Regards,
Andy Shevchenko

Re: LED subsystem lagging maintenance

[Andy Shevchenko]

On Wed, Jul 28, 2021 at 1:36 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, Jul 28, 2021 at 01:26:20PM +0300, Andy Shevchenko wrote:
> > Hi!
> >
> > I have noticed that in the last couple of cycles the LED subsystem is
> > a bit laggish in terms of maintenance (*). I think it's time that
> > someone can help Pavel to sort things out.
> >
> > In any case, I wonder if we have any kind of procedure for what to do
> > in such cases. Do we need to assume that the subsystem is in a
> > (pre-)orphaned state? If so, who is the best to take care of patch
> > flow?
>
> What outstanding patches have not been handled?  Have you talked to
> Pavel about this?

Pavel has known about them I believe. But just for your convenience
https://lore.kernel.org/linux-leds/20210529111935.3849707-1-andy.shevchenko@gmail.com/T/#u

> > *) e.g. I have a series against a few drivers in LED with actual fixes
> > and it is missed v5.13 (okay, that time Pavel had comments which I
> > have addressed at ~rc7 time frame), missed v5.14 and seems on the
> > curve to miss v5.15.
>
> If you address something at -rc7 you should not expect the changes to be
> merged in time for the next release, what would you do if you were on
> the other end?

Yes, that's why skipping v5.13 is okay, but v5.14 is completely out after that.

> > P.S. I Cc'ed lately active, AFAICS, in that area people + Greg for his opinion.
>
> I think that Pavel should be the one asking for help here if he needs
> it.

I hope so. And we won't see the series dangling for 2 month without
any single word from a maintainer. Thanks for your reply!

-- 
With Best Regards,
Andy Shevchenko

Re: LED subsystem lagging maintenance

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

Hi!

> Thanks for your _prompt_ response!
> 
> > > I have noticed that in the last couple of cycles the LED subsystem is
> > > a bit laggish in terms of maintenance (*). I think it's time that
> > > someone can help Pavel to sort things out.
> > >
> > > In any case, I wonder if we have any kind of procedure for what to do
> > > in such cases. Do we need to assume that the subsystem is in a
> > > (pre-)orphaned state? If so, who is the best to take care of patch
> > > flow?
> 
> > To be honest, patches were not applied because they were not that
> > important to begin with,
> 
> Reference counting disbalance is not critical, but what is then?

Things with end-user impact. What is end-user impact here? How much
memory is leaked in usual config?

								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: LED subsystem lagging maintenance

[Andy Shevchenko]

On Wed, Jul 28, 2021 at 2:17 PM Pavel Machek <pavel@ucw.cz> wrote:

...

> > > To be honest, patches were not applied because they were not that
> > > important to begin with,
> >
> > Reference counting disbalance is not critical, but what is then?
>
> Things with end-user impact. What is end-user impact here? How much
> memory is leaked in usual config?

Not sure what "usual" means, but if the user has a device in question,
then it's struct fwnode_handle (7 pointers + u8, unpacked) per each
modprobe. Taking into account that there are usually not so many of
the same LED devices in the system  and the user rarely does
rmmod/insmod cycle, I can say a few dozens of bytes.


-- 
With Best Regards,
Andy Shevchenko

Re: LED subsystem lagging maintenance

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

Hi!

> >> I have noticed that in the last couple of cycles the LED subsystem is
> >> a bit laggish in terms of maintenance (*). I think it's time that
> >> someone can help Pavel to sort things out.
> >>
> >> In any case, I wonder if we have any kind of procedure for what to do
> >> in such cases. Do we need to assume that the subsystem is in a
> >> (pre-)orphaned state? If so, who is the best to take care of patch
> >> flow?
> > 
> > To be honest, patches were not applied because they were not that
> > important to begin with, because of lacking explanation, and because
> > you pushed a bit too hard.
> > 
> > Yes, I'm quite busy in -rc1 to -rc3 timeframe with stable reviews. No,
> > LED subsystem is not orphaned.
> 
> It is good to hear that you are still actively maintaining the LED
> subsystem, thank you.
> 
> This thread does remind me that I was planning on re-sending this
> LED patch which seems to have fallen through the cracks:
> 
> https://lore.kernel.org/alsa-devel/20210221115208.105203-1-hdegoede@redhat.com/
> 
> Can you pick this one up please? Or shall I resend it?

Thanks, applied.

							Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: LED subsystem lagging maintenance

[Andy Shevchenko]

On Wed, Aug 4, 2021 at 12:58 AM Pavel Machek <pavel@ucw.cz> wrote:
> > >> I have noticed that in the last couple of cycles the LED subsystem is
> > >> a bit laggish in terms of maintenance (*). I think it's time that
> > >> someone can help Pavel to sort things out.
> > >>
> > >> In any case, I wonder if we have any kind of procedure for what to do
> > >> in such cases. Do we need to assume that the subsystem is in a
> > >> (pre-)orphaned state? If so, who is the best to take care of patch
> > >> flow?
> > >
> > > To be honest, patches were not applied because they were not that
> > > important to begin with, because of lacking explanation, and because
> > > you pushed a bit too hard.
> > >
> > > Yes, I'm quite busy in -rc1 to -rc3 timeframe with stable reviews. No,
> > > LED subsystem is not orphaned.
> >
> > It is good to hear that you are still actively maintaining the LED
> > subsystem, thank you.
> >
> > This thread does remind me that I was planning on re-sending this
> > LED patch which seems to have fallen through the cracks:
> >
> > https://lore.kernel.org/alsa-devel/20210221115208.105203-1-hdegoede@redhat.com/
> >
> > Can you pick this one up please? Or shall I resend it?
>
> Thanks, applied.

Thank you, Pavel! Sorry for being a bit pushy.


-- 
With Best Regards,
Andy Shevchenko

Re: LED subsystem lagging maintenance

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

Hi!

> > > This thread does remind me that I was planning on re-sending this
> > > LED patch which seems to have fallen through the cracks:
> > >
> > > https://lore.kernel.org/alsa-devel/20210221115208.105203-1-hdegoede@redhat.com/
> > >
> > > Can you pick this one up please? Or shall I resend it?
> >
> > Thanks, applied.
> 
> Thank you, Pavel! Sorry for being a bit pushy.

That was reply to Hans' patch. I applied most of yours, too (see the
thread), but some work remains there.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]