Hi Pavel,
On 5/1/19 8:36 PM, Pavel Machek wrote:
Hi!
There are races between "main" thread and workqueue. They manifest
themselves on Thinkpad X60:
This should result in LED blinking, but it turns it off instead:
root@amd:/data/pavel# cd /sys/class/leds/tpacpi\:\:power
root@amd:/sys/class/leds/tpacpi::power# echo timer > trigger
root@amd:/sys/class/leds/tpacpi::power# echo timer > trigger
root@amd:/sys/class/leds/tpacpi::power#
I believe this line is redundant, so I removed it.
It should be possible to transition from blinking to solid on by echo
0 > brightness; echo 1 > brightness... but that does not work, either,
if done too quickly.
Synchronization of the workqueue fixes both.
Signed-off-by: Pavel Machek <pavel@xxxxxx>
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 68aa923..dcb59c8 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -57,6 +57,7 @@ static ssize_t brightness_store(struct device *dev,
if (state == LED_OFF)
led_trigger_remove(led_cdev);
led_set_brightness(led_cdev, state);
+ flush_work(&led_cdev->set_brightness_work);
Is this really required here? It creates non-uniform brightness
setting behavior depending on whether it is set from sysfs or
by in-kernel call to led_set_brightness().
This fixes the echo 0 > brightness; echo 1 > brightness. It has to be
at a place where we can sleep.
If you have better idea, it is welcome, but it would be good to fix
the bug.
Currently not, so I applied the patch in this shape.
--
Best regards,
Jacek Anaszewski
_______________________________________________
ibm-acpi-devel mailing list
ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
