All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "Ondřej Jirman" <megous@megous.com>,
	linux-kernel@vger.kernel.org,
	"Jacek Anaszewski" <jacek.anaszewski@gmail.com>,
	"Dan Murphy" <dmurphy@ti.com>,
	"open list:LED SUBSYSTEM" <linux-leds@vger.kernel.org>,
	marek.behun@nic.cz
Subject: Re: [PATCH RFC] leds: Add support for per-LED device triggers
Date: Sun, 12 Jul 2020 21:11:11 +0200	[thread overview]
Message-ID: <20200712191111.GA20592@amd> (raw)
In-Reply-To: <20200712134911.r3lig4hgyqhmslth@core.my.home>

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

Hi!

> > > > > Some LED controllers may come with an internal HW triggering mechanism
> > > > > for the LED and an ability to switch between user control of the LED,
> > > > > or the internal control. One such example is AXP20X PMIC, that allows
> > > > > wither for user control of the LED, or for internal control based on
> > > > > the state of the battery charger.
> > > > > 
> > > > > Add support for registering per-LED device trigger.
> > > > > 
> > > > > Names of private triggers need to be globally unique, but may clash
> > > > > with other private triggers. This is enforced during trigger
> > > > > registration. Developers can register private triggers just like
> > > > > the normal triggers, by setting private_led to a classdev
> > > > > of the LED the trigger is associated with.
> > > > 
> > > > What about this? Should address Marek's concerns about resource use...
> > > 
> > > What concerns? Marek's concerns seem to be about case where we register
> > > a trigger for (each led * self-working configuration) which I admit
> > > can be quite a lot of triggers if there are many functions. But that's
> > > not my proposal.
> > > 
> > > My proposal is to only register on trigger per LED at most. So on my
> > > system that's 1 extra trigger and on Marek's system that'd be 48 new
> > > triggers. Neither seems like a meaningful problem from resource
> > > use perspective.
> > 
> > So.. 48 triggers on Marek's systems means I'll not apply your patch.
> > 
> > Please take a look at my version, it is as simple and avoids that
> > problem.
> 
> I would, but I don't see your version linked or mentioned in this
> thread.

Ah! Sorry about that. Here it is. (I verified it compiles in the
meantime).

Best regards,
								Pavel

diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 79e30d2cb7a5..e8333675959c 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -27,6 +27,12 @@ LIST_HEAD(trigger_list);
 
  /* Used by LED Class */
 
+static inline bool
+trigger_relevant(struct led_classdev *led_cdev, struct led_trigger *trig)
+{
+	return !trig->trigger_type || trig->trigger_type == led_cdev->trigger_type;
+}
+
 ssize_t led_trigger_write(struct file *filp, struct kobject *kobj,
 			  struct bin_attribute *bin_attr, char *buf,
 			  loff_t pos, size_t count)
@@ -50,7 +56,8 @@ ssize_t led_trigger_write(struct file *filp, struct kobject *kobj,
 
 	down_read(&triggers_list_lock);
 	list_for_each_entry(trig, &trigger_list, next_trig) {
-		if (sysfs_streq(buf, trig->name)) {
+		if (sysfs_streq(buf, trig->name) &&
+		    trigger_relevant(led_cdev, trig)) {
 			down_write(&led_cdev->trigger_lock);
 			led_trigger_set(led_cdev, trig);
 			up_write(&led_cdev->trigger_lock);
@@ -96,6 +103,9 @@ static int led_trigger_format(char *buf, size_t size,
 		bool hit = led_cdev->trigger &&
 			!strcmp(led_cdev->trigger->name, trig->name);
 
+		if (!trigger_relevant(led_cdev, trig))
+			continue;
+
 		len += led_trigger_snprintf(buf + len, size - len,
 					    " %s%s%s", hit ? "[" : "",
 					    trig->name, hit ? "]" : "");
@@ -243,7 +253,8 @@ void led_trigger_set_default(struct led_classdev *led_cdev)
 	down_read(&triggers_list_lock);
 	down_write(&led_cdev->trigger_lock);
 	list_for_each_entry(trig, &trigger_list, next_trig) {
-		if (!strcmp(led_cdev->default_trigger, trig->name)) {
+		if (!strcmp(led_cdev->default_trigger, trig->name) &&
+		    trigger_relevant(led_cdev, trig)) {
 			led_cdev->flags |= LED_INIT_DEFAULT_TRIGGER;
 			led_trigger_set(led_cdev, trig);
 			break;
@@ -280,7 +291,8 @@ int led_trigger_register(struct led_trigger *trig)
 	down_write(&triggers_list_lock);
 	/* Make sure the trigger's name isn't already in use */
 	list_for_each_entry(_trig, &trigger_list, next_trig) {
-		if (!strcmp(_trig->name, trig->name)) {
+		if (!strcmp(_trig->name, trig->name) &&
+		    (!_trig->private_led || _trig->private_led == trig->private_led)) {
 			up_write(&triggers_list_lock);
 			return -EEXIST;
 		}
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 2451962d1ec5..cba52714558f 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -57,6 +57,10 @@ struct led_init_data {
 	bool devname_mandatory;
 };
 
+struct led_hw_trigger_type {
+	int dummy;
+}
+
 struct led_classdev {
 	const char		*name;
 	enum led_brightness	 brightness;
@@ -150,6 +154,8 @@ struct led_classdev {
 
 	/* Ensures consistent access to the LED Flash Class device */
 	struct mutex		led_access;
+
+	struct led_hw_trigger_type *trigger_type;
 };
 
 /**
@@ -345,6 +351,9 @@ struct led_trigger {
 	int		(*activate)(struct led_classdev *led_cdev);
 	void		(*deactivate)(struct led_classdev *led_cdev);
 
+	/* LED-private triggers have this set. */
+	struct led_hw_trigger_type *trigger_type;
+
 	/* LEDs under control by this trigger (for simple triggers) */
 	rwlock_t	  leddev_list_lock;
 	struct list_head  led_cdevs;

-- 
(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 --]

  reply	other threads:[~2020-07-12 19:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-02 14:47 [PATCH RFC] leds: Add support for per-LED device triggers Ondrej Jirman
2020-07-02 14:51 ` Ondřej Jirman
2020-07-03 10:06 ` Marek Behún
2020-07-03 13:08   ` Ondřej Jirman
2020-07-08 14:55     ` Marek Behún
2020-07-04 12:59   ` Pavel Machek
2020-07-08 14:56     ` Marek Behún
2020-07-04 12:04 ` Pavel Machek
2020-07-04 12:17   ` Ondřej Jirman
2020-07-04 20:07     ` Pavel Machek
2020-07-11 10:04 ` Pavel Machek
2020-07-11 21:01   ` Ondřej Jirman
2020-07-12  7:25     ` Pavel Machek
2020-07-12 13:49       ` Ondřej Jirman
2020-07-12 19:11         ` Pavel Machek [this message]
2020-07-12 21:10           ` Marek Behun
2020-07-12 22:12           ` Ondřej Jirman
2020-07-12 22:38           ` Ondřej Jirman
2020-07-12 23:15             ` Marek Behun
2020-07-12 23:18               ` Marek Behun
2020-07-13  7:12                 ` Pavel Machek
2020-07-12 23:20               ` Ondřej Jirman
2020-07-13  1:56           ` Ondřej Jirman
2020-07-15 17:07   ` Marek Behún
2020-07-15 17:55     ` Marek Behún

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200712191111.GA20592@amd \
    --to=pavel@ucw.cz \
    --cc=dmurphy@ti.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=marek.behun@nic.cz \
    --cc=megous@megous.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.