|
From: Jacek A. <jac...@gm...> - 2019-05-01 16:42:05
|
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 <pa...@uc...>
>
> 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
|
