Re: [PATCH] leds: fix brightness changing when software blinking is active

From: Jacek Anaszewski
Date: Thu May 14 2015 - 08:09:30 EST


On 05/14/2015 01:03 PM, Stas Sergeev wrote:
14.05.2015 13:33, Jacek Anaszewski ÐÐÑÐÑ:
Indeed, but with these changes there should be no requirement
for disabling a soft-blink from hard-irq context, which is what
I really wanted to have. What am I missing?
Please look at this [1]. Author mentions setting brightness
from sound-card irq handler.

[1] http://www.spinics.net/lists/linux-leds/msg00006.html
He points to the following (out-of-tree??) code:
---
if ((jiffies / HZ / 2) & 1)
led_trigger_blink_oneshot(ledtrig_ide,
&ide_blink_delay, &ide_blink_delay, 0);
if ((jiffies / HZ / 4) & 1)
led_trigger_event(ledtrig_ide, 100);
if ((jiffies / HZ / 8) & 1)
led_trigger_event(ledtrig_ide, 0);
---
I think the problem was that oneshot_trig_deactivate() was
not doing led_stop_software_blink(led_cdev), and so he needed
a work-queue for switching out from oneshot trigger.
My patch fixes exactly that: now oneshot trigger does the
proper cleanup itself.
Do you think my patch is not enough to handle this case?


This problem is related to the issue of locking between hard IRQ
and Softirqs [1]. I've just discovered also that there had been already
an attempt [2] of using work queue internally in led_set_brightness,
but it wouldn't have found its way to the mainline. Probably for a
reason.

[1] https://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/c188.html
[2] http://www.serverphorums.com/read.php?12,563432

--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/