Hi Pavel,
Thank you for the patch.
On 4/29/19 5:22 PM, Pavel Machek wrote:
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#
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().
ret = size;
unlock:
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 9f8da39..aefac4d 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -166,6 +166,11 @@ static void led_blink_setup(struct led_classdev *led_cdev,
unsigned long *delay_on,
unsigned long *delay_off)
{
+ /*
+ * If "set brightness to 0" is pending in workqueue, we don't
+ * want that to be reordered after blink_set()
+ */
+ flush_work(&led_cdev->set_brightness_work);
if (!test_bit(LED_BLINK_ONESHOT, &led_cdev->work_flags) &&
led_cdev->blink_set &&
!led_cdev->blink_set(led_cdev, delay_on, delay_off))
--
Best regards,
Jacek Anaszewski
