Linux-LEDs Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH 1/2] leds: Add flag to keep trigger always
@ 2019-08-10  0:52 Guru Das Srinagesh
  2019-08-10  0:52 ` [PATCH 2/2] leds: triggers: Don't remove trigger if LED_KEEP_TRIGGER flag is set Guru Das Srinagesh
  2019-08-10  7:13 ` [PATCH 1/2] leds: Add flag to keep trigger always Pavel Machek
  0 siblings, 2 replies; 9+ messages in thread
From: Guru Das Srinagesh @ 2019-08-10  0:52 UTC (permalink / raw)
  To: linux-leds
  Cc: Jacek Anaszewski, Pavel Machek, Dan Murphy, linux-kernel,
	Subbaraman Narayanamurthy, Guru Das Srinagesh

From: Subbaraman Narayanamurthy <subbaram@codeaurora.org>

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 <subbaram@codeaurora.org>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/leds/led-class.c | 2 +-
 include/linux/leds.h     | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index d231240..13c28d1 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -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);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index d101fd1..e079a22 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -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;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH 2/2] leds: triggers: Don't remove trigger if LED_KEEP_TRIGGER flag is set
  2019-08-10  0:52 [PATCH 1/2] leds: Add flag to keep trigger always Guru Das Srinagesh
@ 2019-08-10  0:52 ` Guru Das Srinagesh
  2019-08-10  7:13 ` [PATCH 1/2] leds: Add flag to keep trigger always Pavel Machek
  1 sibling, 0 replies; 9+ messages in thread
From: Guru Das Srinagesh @ 2019-08-10  0:52 UTC (permalink / raw)
  To: linux-leds
  Cc: Jacek Anaszewski, Pavel Machek, Dan Murphy, linux-kernel,
	Fenglin Wu, Guru Das Srinagesh

From: Fenglin Wu <fenglinw@codeaurora.org>

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 <fenglinw@codeaurora.org>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/leds/led-triggers.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 8d11a5e..a0e4531 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -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;
 	}
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] leds: Add flag to keep trigger always
  2019-08-10  0:52 [PATCH 1/2] leds: Add flag to keep trigger always Guru Das Srinagesh
  2019-08-10  0:52 ` [PATCH 2/2] leds: triggers: Don't remove trigger if LED_KEEP_TRIGGER flag is set Guru Das Srinagesh
@ 2019-08-10  7:13 ` Pavel Machek
  2019-09-30 13:39   ` Greg KH
  1 sibling, 1 reply; 9+ messages in thread
From: Pavel Machek @ 2019-08-10  7:13 UTC (permalink / raw)
  To: Guru Das Srinagesh
  Cc: linux-leds, Jacek Anaszewski, Dan Murphy, linux-kernel,
	Subbaraman Narayanamurthy

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On Fri 2019-08-09 17:52:46, Guru Das Srinagesh wrote:
> From: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
> 
> 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


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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] leds: Add flag to keep trigger always
  2019-08-10  7:13 ` [PATCH 1/2] leds: Add flag to keep trigger always Pavel Machek
@ 2019-09-30 13:39   ` Greg KH
  2019-09-30 17:22     ` Pavel Machek
  0 siblings, 1 reply; 9+ messages in thread
From: Greg KH @ 2019-09-30 13:39 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Guru Das Srinagesh, linux-leds, Jacek Anaszewski, Dan Murphy,
	linux-kernel, Subbaraman Narayanamurthy

On Sat, Aug 10, 2019 at 09:13:22AM +0200, Pavel Machek wrote:
> On Fri 2019-08-09 17:52:46, Guru Das Srinagesh wrote:
> > From: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
> > 
> > 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.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] leds: Add flag to keep trigger always
  2019-09-30 13:39   ` Greg KH
@ 2019-09-30 17:22     ` Pavel Machek
  2019-09-30 17:27       ` Greg KH
  0 siblings, 1 reply; 9+ messages in thread
From: Pavel Machek @ 2019-09-30 17:22 UTC (permalink / raw)
  To: Greg KH
  Cc: Guru Das Srinagesh, linux-leds, Jacek Anaszewski, Dan Murphy,
	linux-kernel, Subbaraman Narayanamurthy

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

On Mon 2019-09-30 15:39:02, Greg KH wrote:
> On Sat, Aug 10, 2019 at 09:13:22AM +0200, Pavel Machek wrote:
> > On Fri 2019-08-09 17:52:46, Guru Das Srinagesh wrote:
> > > From: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
> > > 
> > > 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.
> 
> 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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] leds: Add flag to keep trigger always
  2019-09-30 17:22     ` Pavel Machek
@ 2019-09-30 17:27       ` Greg KH
  2019-10-04 20:09         ` Guru Das Srinagesh
  0 siblings, 1 reply; 9+ messages in thread
From: Greg KH @ 2019-09-30 17:27 UTC (permalink / raw)
  To: Pavel Machek, Guru Das Srinagesh
  Cc: linux-leds, Jacek Anaszewski, Dan Murphy, linux-kernel,
	Subbaraman Narayanamurthy

On Mon, Sep 30, 2019 at 07:22:39PM +0200, Pavel Machek wrote:
> On Mon 2019-09-30 15:39:02, Greg KH wrote:
> > On Sat, Aug 10, 2019 at 09:13:22AM +0200, Pavel Machek wrote:
> > > On Fri 2019-08-09 17:52:46, Guru Das Srinagesh wrote:
> > > > From: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
> > > > 
> > > > 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.
> > 
> > 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...

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] leds: Add flag to keep trigger always
  2019-09-30 17:27       ` Greg KH
@ 2019-10-04 20:09         ` Guru Das Srinagesh
  2019-10-08  7:47           ` Pavel Machek
  0 siblings, 1 reply; 9+ messages in thread
From: Guru Das Srinagesh @ 2019-10-04 20:09 UTC (permalink / raw)
  To: Greg KH
  Cc: Pavel Machek, linux-leds, Jacek Anaszewski, Dan Murphy,
	linux-kernel, Subbaraman Narayanamurthy

On Mon, Sep 30, 2019 at 07:27:43PM +0200, Greg KH wrote:
> On Mon, Sep 30, 2019 at 07:22:39PM +0200, Pavel Machek wrote:
> > On Mon 2019-09-30 15:39:02, Greg KH wrote:
> > > On Sat, Aug 10, 2019 at 09:13:22AM +0200, Pavel Machek wrote:
> > > > On Fri 2019-08-09 17:52:46, Guru Das Srinagesh wrote:
> > > > > From: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
> > > > > 
> > > > > 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.
> > > 
> > > 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...
> 
> 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

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] leds: Add flag to keep trigger always
  2019-10-04 20:09         ` Guru Das Srinagesh
@ 2019-10-08  7:47           ` Pavel Machek
  2019-10-10  0:52             ` Guru Das Srinagesh
  0 siblings, 1 reply; 9+ messages in thread
From: Pavel Machek @ 2019-10-08  7:47 UTC (permalink / raw)
  To: Guru Das Srinagesh
  Cc: Greg KH, linux-leds, Jacek Anaszewski, Dan Murphy, linux-kernel,
	Subbaraman Narayanamurthy

[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]

Hi!

> > > > 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...
> > 
> > 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
> 
> 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.

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
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] leds: Add flag to keep trigger always
  2019-10-08  7:47           ` Pavel Machek
@ 2019-10-10  0:52             ` Guru Das Srinagesh
  0 siblings, 0 replies; 9+ messages in thread
From: Guru Das Srinagesh @ 2019-10-10  0:52 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Greg KH, linux-leds, Jacek Anaszewski, Dan Murphy, linux-kernel,
	Subbaraman Narayanamurthy

On Tue, Oct 08, 2019 at 09:47:31AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > 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...
> > > 
> > > 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
> > 
> > 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.
> 
> 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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-10  0:52 [PATCH 1/2] leds: Add flag to keep trigger always Guru Das Srinagesh
2019-08-10  0:52 ` [PATCH 2/2] leds: triggers: Don't remove trigger if LED_KEEP_TRIGGER flag is set Guru Das Srinagesh
2019-08-10  7:13 ` [PATCH 1/2] leds: Add flag to keep trigger always Pavel Machek
2019-09-30 13:39   ` Greg KH
2019-09-30 17:22     ` Pavel Machek
2019-09-30 17:27       ` Greg KH
2019-10-04 20:09         ` Guru Das Srinagesh
2019-10-08  7:47           ` Pavel Machek
2019-10-10  0:52             ` Guru Das Srinagesh

Linux-LEDs Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-leds/0 linux-leds/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-leds linux-leds/ https://lore.kernel.org/linux-leds \
		linux-leds@vger.kernel.org linux-leds@archiver.kernel.org
	public-inbox-index linux-leds

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-leds


AGPL code for this site: git clone https://public-inbox.org/ public-inbox