Re: [Linux-stable-mirror] [PATCH AUTOSEL for 4.14 065/110] led: core: Fix brightness setting when setting delay_off=0
On Sun, Feb 04, 2018 at 06:17:36PM +0100, Pavel Machek wrote:
*** if brightness=0, led off *** else apply brightness if next timer <--- timer is stop, and will never apply new setting ** otherwise set led_set_brightness_nosleep
To fix that, when we delete the timer, we should clear LED_BLINK_SW.
Can you run the tests on the affected stable kernels? I have feeling that the problem described might not be present there.
Hm, I don't seem to have HW to test that out. Maybe someone else does?
Why are you submitting patches you have no way to test?
What? This is stable tree backporting, why are you trying to make a requirement for something that we have never had before?
I don't think random patches should be sent to stable just because they appeared in mainline. Plus, I don't think I'm making new rules:
submit-checklist.rst:
- Has been build- and runtime tested with and without ``CONFIG_SMP``
and ``CONFIG_PREEMPT.``
stable-kernel-rules.rst:
Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree:
- It must be obviously correct and tested.
- It must fix a real bug that bothers people (not a, "This could be a problem..." type thing).
So you're saying that this doesn't qualify as a bug?
This is a backport of a patch that is already upstream. If it doesn't belong in a stable tree, great, let us know that, saying why it is so.
See jacek.anaszewski@gmail.com 's explanation.
I might be missing something, but Jacek suggested I pull another patch before this one?
On 02/06/2018 03:02 AM, Sasha Levin wrote:
On Sun, Feb 04, 2018 at 06:17:36PM +0100, Pavel Machek wrote:
> *** if brightness=0, led off > *** else apply brightness if next timer <--- timer is stop, and will never apply new setting > ** otherwise set led_set_brightness_nosleep > > To fix that, when we delete the timer, we should clear LED_BLINK_SW.
Can you run the tests on the affected stable kernels? I have feeling that the problem described might not be present there.
Hm, I don't seem to have HW to test that out. Maybe someone else does?
Why are you submitting patches you have no way to test?
What? This is stable tree backporting, why are you trying to make a requirement for something that we have never had before?
I don't think random patches should be sent to stable just because they appeared in mainline. Plus, I don't think I'm making new rules:
submit-checklist.rst:
- Has been build- and runtime tested with and without ``CONFIG_SMP``
and ``CONFIG_PREEMPT.``
stable-kernel-rules.rst:
Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree:
- It must be obviously correct and tested.
- It must fix a real bug that bothers people (not a, "This could be a problem..." type thing).
So you're saying that this doesn't qualify as a bug?
This is a backport of a patch that is already upstream. If it doesn't belong in a stable tree, great, let us know that, saying why it is so.
See jacek.anaszewski@gmail.com 's explanation.
I might be missing something, but Jacek suggested I pull another patch before this one?
Just to clarify:
For 4.14 below patches are chosen correctly:
[PATCH AUTOSEL for 4.14 065/110] led: core: Fix brightness setting when setting delay_off=0 [PATCH AUTOSEL for 4.14 094/110] leds: core: Fix regression caused by commit 2b83ff96f51d
For 4.9 both above patches are needed preceded by:
eb1610b4c273 ("led: core: Fix blink_brightness setting race")
The issue the patch [PATCH AUTOSEL for 4.14 065/110] fixes was introduced in 4.7, and thus it should be removed from the series for 3.18 and 4.4.
linux-stable-mirror@lists.linaro.org
-
Jacek Anaszewski -
Sasha Levin