From: Pavel Machek <pavel@ucw.cz>
To: Marek Behun <marek.behun@nic.cz>
Cc: "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>
Subject: Re: [PATCH RFC] leds: Add support for per-LED device triggers
Date: Mon, 13 Jul 2020 09:12:55 +0200 [thread overview]
Message-ID: <20200713071255.GB30654@amd> (raw)
In-Reply-To: <20200713011841.25904273@nic.cz>
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
On Mon 2020-07-13 01:18:41, Marek Behun wrote:
> On Mon, 13 Jul 2020 01:15:44 +0200
> Marek Behun <marek.behun@nic.cz> wrote:
>
> > On Mon, 13 Jul 2020 00:38:21 +0200
> > Ondřej Jirman <megous@megous.com> wrote:
> >
> > > So after trying to use this, this seems to disallow the use of multiple HW
> > > triggers per LED. That's fine by me, because using one HW sysfs configured
> > > trigger per LED that use case is my proposal, but is it desireable in general?
> >
> > Why? If you register one LED and several triggers, all sharing the same
> > trigger_type pointer, I think it should work.
> >
> > Marek
>
> The problem arises when I have two LEDs and two HW triggers, and the
> hardware allows setting one HW trigger on both LEDs and other HW
> trigger only on one LED. But this could simply be ignored - the
> set_trigger function could simply return -ENOTSUPP or something.
In this case you should have two trigger_type pointers (since two LEDs
are different), and yes, you'll have duplication for one of the
triggers. I don't think thats a problem.
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 --]
next prev parent reply other threads:[~2020-07-13 7:12 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
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 [this message]
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=20200713071255.GB30654@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.