|
From: Jacek A. <jac...@gm...> - 2019-05-02 18:29:33
|
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 <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(). > > 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 |
