leds: Add flag to keep trigger always

PATCH In review Guru Das Srinagesh 4 participants 9 messages Aug 10, 2019 – Oct 10, 2019 LED

lore

Share & tools

lore

Guru Das Srinagesh

author

2019-08-10 00:59 UTC #0 lore raw

PATCH 1/2 leds: Add flag to keep trigger always

From: Subbaraman Narayanamurthy <[email protected]>

Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 ("leds: disable triggers on brightness set") removes the trigger on an LED class device when brightness is set to 0. However, there are some LED class devices which need the trigger not to be removed. In a use case like camera flash, camera flash driver passes in a trigger device to LED class driver. If the trigger is removed when the brightness is set to 0, this will affect the clients using those triggers. Hence add a flag to always keep the trigger even when brightness is set to 0.

Signed-off-by Subbaraman Narayanamurthy <[email protected]>

Signed-off-by Guru Das Srinagesh <[email protected]>

---
 drivers/leds/led-class.c | 2 +-
 include/linux/leds.h     | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

drivers/leds/led-class.c +1 -1

index d231240..13c28d1 100644
@@ -52,7 +52,7 @@ static ssize_t brightness_store(struct device *dev,
 	if (ret)
 		goto unlock;
 
-	if (state == LED_OFF)
+	if (state == LED_OFF && !(led_cdev->flags & LED_KEEP_TRIGGER))
 		led_trigger_remove(led_cdev);
 	led_set_brightness(led_cdev, state);
 	flush_work(&led_cdev->set_brightness_work);

include/linux/leds.h +1 -0

index d101fd1..e079a22 100644
@@ -73,6 +73,7 @@ struct led_classdev {
 #define LED_BRIGHT_HW_CHANGED	BIT(21)
 #define LED_RETAIN_AT_SHUTDOWN	BIT(22)
 #define LED_INIT_DEFAULT_TRIGGER BIT(23)
+#define LED_KEEP_TRIGGER	BIT(24)
 
 	/* set_brightness_work / blink_timer flags, atomic, private. */
 	unsigned long		work_flags;

Signature · 2 lines

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Guru Das Srinagesh

author

2019-08-10 00:59 UTC #1 lore raw

PATCH 2/2 leds: triggers: Don't remove trigger if LED_KEEP_TRIGGER flag is set

From: Fenglin Wu <[email protected]>

The LED_KEEP_TRIGGER flag prevents the trigger being removed while turning off the LEDs. Extend the flag usage to prevent the trigger being removed even while "none" trigger is set.

Signed-off-by Fenglin Wu <[email protected]>

Signed-off-by Guru Das Srinagesh <[email protected]>

---
 drivers/leds/led-triggers.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/leds/led-triggers.c +2 -1

index 8d11a5e..a0e4531 100644
@@ -40,7 +40,8 @@ ssize_t led_trigger_store(struct device *dev, struct device_attribute *attr,
 		goto unlock;
 	}
 
-	if (sysfs_streq(buf, "none")) {
+	if (sysfs_streq(buf, "none") &&
+			!(led_cdev->flags & LED_KEEP_TRIGGER)) {
 		led_trigger_remove(led_cdev);
 		goto unlock;
 	}

Signature · 2 lines

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Pavel Machek

2019-08-10 07:13 UTC #2 lore raw

In reply to Guru Das Srinagesh

Quoted 10 lines · Guru Das Srinagesh

From: Subbaraman Narayanamurthy <[email protected]>
Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 ("leds: disable triggers on brightness set") removes the trigger on an LED class device when brightness is set to 0. However, there are some LED class devices which need the trigger not to be removed. In a use case like camera flash, camera flash driver passes in a trigger device to LED class driver. If the trigger is removed when the brightness is set to 0, this will affect the clients using those triggers. Hence add a flag to always keep the trigger even when brightness is set to 0.

No.

Yes, it would affect those clients. Don't do it, then. It is root-only operation.

Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Greg KH

2019-09-30 14:08 UTC #3 lore raw

Quoted 12 lines · Pavel Machek

Quoted 10 lines · Guru Das Srinagesh
From: Subbaraman Narayanamurthy <[email protected]>
Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 ("leds: disable triggers on brightness set") removes the trigger on an LED class device when brightness is set to 0. However, there are some LED class devices which need the trigger not to be removed. In a use case like camera flash, camera flash driver passes in a trigger device to LED class driver. If the trigger is removed when the brightness is set to 0, this will affect the clients using those triggers. Hence add a flag to always keep the trigger even when brightness is set to 0.

Quoted 4 lines

No.
Yes, it would affect those clients. Don't do it, then. It is root-only operation.

I don't understand. The original commit broke userspace operations. Shouldn't it be reverted, or fixed this way in order to have userspace work properly again?

thanks,

greg k-h

Pavel Machek

2019-09-30 20:58 UTC #4 lore raw

Quoted 13 lines · Greg KH

Quoted 12 lines · Pavel Machek
Quoted 10 lines · Guru Das Srinagesh
From: Subbaraman Narayanamurthy <[email protected]>
Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 ("leds: disable triggers on brightness set") removes the trigger on an LED class device when brightness is set to 0. However, there are some LED class devices which need the trigger not to be removed. In a use case like camera flash, camera flash driver passes in a trigger device to LED class driver. If the trigger is removed when the brightness is set to 0, this will affect the clients using those triggers. Hence add a flag to always keep the trigger even when brightness is set to 0.

Quoted 8 lines

Quoted 4 lines
No.
Yes, it would affect those clients. Don't do it, then. It is root-only operation.
I don't understand. The original commit broke userspace operations. Shouldn't it be reverted, or fixed this way in order to have userspace work properly again?

So, what it is exactly that is not working? :-). Yes, root can disconnect LED from v4l2 interface; he can also connect it back. Documentation says that happens.

Yes, root can do stupid things.

Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 is from 2008. I'd prefer we did not apply it in 2008, but...

Best regards,

Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Greg KH

2019-09-30 21:06 UTC #5 lore raw

Quoted 23 lines · Pavel Machek

Quoted 13 lines · Greg KH
Quoted 12 lines · Pavel Machek
Quoted 10 lines · Guru Das Srinagesh
From: Subbaraman Narayanamurthy <[email protected]>
Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 ("leds: disable triggers on brightness set") removes the trigger on an LED class device when brightness is set to 0. However, there are some LED class devices which need the trigger not to be removed. In a use case like camera flash, camera flash driver passes in a trigger device to LED class driver. If the trigger is removed when the brightness is set to 0, this will affect the clients using those triggers. Hence add a flag to always keep the trigger even when brightness is set to 0.
Quoted 8 lines
Quoted 4 lines
No.
Yes, it would affect those clients. Don't do it, then. It is root-only operation.
I don't understand. The original commit broke userspace operations. Shouldn't it be reverted, or fixed this way in order to have userspace work properly again?

Quoted 8 lines

So, what it is exactly that is not working? :-). Yes, root can disconnect LED from v4l2 interface; he can also connect it back. Documentation says that happens.
Yes, root can do stupid things.
Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 is from 2008. I'd prefer we did not apply it in 2008, but...

Ah, my fault, I thought this was a new commit.

Guru, what are you doing here that this is required all of a sudden? No other kernel seems to need these changes, what is different in your Android userspace that requires this patch series?

thanks,

greg k-h

Guru Das Srinagesh

author

2019-10-04 20:09 UTC #6 lore raw

Quoted 35 lines · Greg KH

Quoted 23 lines · Pavel Machek
Quoted 13 lines · Greg KH
Quoted 12 lines · Pavel Machek
Quoted 10 lines · Guru Das Srinagesh
From: Subbaraman Narayanamurthy <[email protected]>
Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 ("leds: disable triggers on brightness set") removes the trigger on an LED class device when brightness is set to 0. However, there are some LED class devices which need the trigger not to be removed. In a use case like camera flash, camera flash driver passes in a trigger device to LED class driver. If the trigger is removed when the brightness is set to 0, this will affect the clients using those triggers. Hence add a flag to always keep the trigger even when brightness is set to 0.
Quoted 8 lines
Quoted 4 lines
No.
Yes, it would affect those clients. Don't do it, then. It is root-only operation.
I don't understand. The original commit broke userspace operations. Shouldn't it be reverted, or fixed this way in order to have userspace work properly again?
Quoted 8 lines
So, what it is exactly that is not working? :-). Yes, root can disconnect LED from v4l2 interface; he can also connect it back. Documentation says that happens.
Yes, root can do stupid things.
Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 is from 2008. I'd prefer we did not apply it in 2008, but...
Ah, my fault, I thought this was a new commit.

Quoted 7 lines

Guru, what are you doing here that this is required all of a sudden? No other kernel seems to need these changes, what is different in your Android userspace that requires this patch series?
thanks,
greg k-h

Hi Greg,

Our camera flash driver first requests the available current from the flash LED before setting its brightness. It passes a trigger as argument to the function that determines the available current. This function uses trigger_to_lcdev() to look up the led_classdev associated with that trigger as a first step. This lookup will fail if the trigger has been dissociated from its led_classdev as a result of a user setting that led_classdev's brightness to zero manually through sysfs.

Why would the user set the brightness to zero? The user does this as part of camera and LED testing activities which include, amongst other things, visual inspection of the operation of various onboard LEDs. The user uses sysfs to manually turn on and off the LEDs by setting their brightness to max and then to zero in order to verify that they are working as expected.

So what happens if the user, having turned off the flash LED after an inspection, wishes to move on to testing the userspace camera app? The userspace camera app will not be able to utilize the flash LED for any of its functions due to the led_classdev lookup failure. The user has no choice but to reboot the device to continue with his testing.

Therefore, to summarize, this patch is being utilized in our downstream kernel (for a few years now) to support aforementioned testing activities, and so we thought it might be a good idea to upstream this patch now.

Pavel Machek

2019-10-08 07:47 UTC #7 lore raw

Hi!

Quoted 33 lines

Quoted 15 lines
Quoted 4 lines
Quoted 3 lines
I don't understand. The original commit broke userspace operations. Shouldn't it be reverted, or fixed this way in order to have userspace work properly again?
Quoted 8 lines
So, what it is exactly that is not working? :-). Yes, root can disconnect LED from v4l2 interface; he can also connect it back. Documentation says that happens.
Yes, root can do stupid things.
Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 is from 2008. I'd prefer we did not apply it in 2008, but...
Ah, my fault, I thought this was a new commit.
Quoted 7 lines
Guru, what are you doing here that this is required all of a sudden? No other kernel seems to need these changes, what is different in your Android userspace that requires this patch series?
thanks,
greg k-h
Hi Greg,
Our camera flash driver first requests the available current from the flash LED before setting its brightness. It passes a trigger as argument to the function that determines the available current. This function uses trigger_to_lcdev() to look up the led_classdev associated with that trigger as a first step. This lookup will fail if the trigger has been dissociated from its led_classdev as a result of a user setting that led_classdev's brightness to zero manually through sysfs.

Quoted 6 lines

Why would the user set the brightness to zero? The user does this as part of camera and LED testing activities which include, amongst other things, visual inspection of the operation of various onboard LEDs. The user uses sysfs to manually turn on and off the LEDs by setting their brightness to max and then to zero in order to verify that they are working as expected.

Yes, so you should really set trigger to none before changing brightness manually and restore it back to whatever it was when you are done with manual testing.

Thanks,
Pavel

Signature · 2 lines

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Guru Das Srinagesh

author

2019-10-10 00:52 UTC #8 lore raw

Quoted 42 lines · Pavel Machek

Hi!
Quoted 33 lines
Quoted 15 lines
Quoted 4 lines
Quoted 3 lines
I don't understand. The original commit broke userspace operations. Shouldn't it be reverted, or fixed this way in order to have userspace work properly again?
Quoted 8 lines
So, what it is exactly that is not working? :-). Yes, root can disconnect LED from v4l2 interface; he can also connect it back. Documentation says that happens.
Yes, root can do stupid things.
Commit 0013b23d66a2768f5babbb0ea9f03ab067a990d8 is from 2008. I'd prefer we did not apply it in 2008, but...
Ah, my fault, I thought this was a new commit.
Quoted 7 lines
Guru, what are you doing here that this is required all of a sudden? No other kernel seems to need these changes, what is different in your Android userspace that requires this patch series?
thanks,
greg k-h
Hi Greg,
Our camera flash driver first requests the available current from the flash LED before setting its brightness. It passes a trigger as argument to the function that determines the available current. This function uses trigger_to_lcdev() to look up the led_classdev associated with that trigger as a first step. This lookup will fail if the trigger has been dissociated from its led_classdev as a result of a user setting that led_classdev's brightness to zero manually through sysfs.
Quoted 6 lines
Why would the user set the brightness to zero? The user does this as part of camera and LED testing activities which include, amongst other things, visual inspection of the operation of various onboard LEDs. The user uses sysfs to manually turn on and off the LEDs by setting their brightness to max and then to zero in order to verify that they are working as expected.

Quoted 3 lines

Yes, so you should really set trigger to none before changing brightness manually and restore it back to whatever it was when you are done with manual testing.

Hi Pavel,

Tried your suggestion to set the trigger to "none" before manual testing and to restore it afterwards, and it works.

Thanks a lot.