linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Lechner <david@lechnology.com>
To: Baolin Wang <baolin.wang@linaro.org>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Mark Brown <broonie@kernel.org>,
	Linux LED Subsystem <linux-leds@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface
Date: Sun, 15 Jul 2018 20:00:32 -0500	[thread overview]
Message-ID: <2c3a8911-150a-9b25-2a66-a9432047f96b@lechnology.com> (raw)
In-Reply-To: <1138f834-e805-6076-bb5b-aa1fdc1f2606@gmail.com>

On 07/15/2018 07:22 AM, Jacek Anaszewski wrote:
> On 07/15/2018 12:39 AM, Pavel Machek wrote:
>> On Sun 2018-07-15 00:29:25, Pavel Machek wrote:
>>> On Sun 2018-07-15 00:02:57, Jacek Anaszewski wrote:
>>>> Hi Pavel,
>>>>
>>>> On 07/14/2018 11:20 PM, Pavel Machek wrote:
>>>>> Hi!
>>>>>
>>>>>>> It also drew my attention to the issue of desired pattern sysfs
>>>>>>> interface semantics on uninitialized pattern. In your implementation
>>>>>>> user seems to be unable to determine if the pattern is activated
>>>>>>> or not. We should define the semantics for this use case and
>>>>>>> describe it in the documentation. Possibly pattern could
>>>>>>> return alone new line character then.
>>>>>
>>>>> Let me take a step back: we have triggers.. like LED blinking.
>>>>>
>>>>> How is that going to interact with patterns? We probably want the
>>>>> patterns to be ignored in that case...?
>>>>>
>>>>> Which suggest to me that we should treat patterns as a trigger. I
>>>>> believe we do something similar with blinking already.
>>>>>
>>>>> Then it is easy to determine if pattern is active, and pattern
>>>>> vs. trigger issue is solved automatically.
>>>>
>>>> I'm all for it. I proposed this approach during the previous
>>>> discussions related to possible pattern interface implementations,
>>>> but you seemed not to be so enthusiastic in [0].
>>>>
>>>> [0] https://lkml.org/lkml/2017/4/7/350
>>>
>>> Hmm. Reading my own email now, I can't decipher it.
>>>
>>> I believe I meant "changing patterns from kernel in response to events
>>> is probably overkill"... or something like that.
>>
>> Anyway -- to clean up the confusion -- I'd like to see
>>
>> echo pattern > trigger
>> echo "1 2 3 4 5 6 7 8" > somewhere
> 
> s/somewhere/pattern/
> 
> pattern trigger should create "pattern" file similarly how ledtrig-timer
> creates delay_{on|off} files.
> 

I don't think this is the best way. For example, if you want more than one
LED to have the same pattern, then the patterns will not be synchronized
between the LEDs. The same things happens now with many of the existing
triggers. For example, if I have two LEDs side-by-side using the heartbeat
trigger, they may blink at the same time or they may not, which is not
very nice. I think we can make something better.

Perhaps a way to do this would be to use configfs to create a pattern
trigger that can be shared by multiple LEDs. Like this:

     mkdir /sys/kernel/config/leds/triggers/my-nice-pattern
     echo "1 2 3 4" > /sys/kernel/config/leds/triggers/my-nice-pattern/pattern
     echo my-nice-pattern > /sys/class/leds/led0/trigger
     echo my-nice-pattern > /sys/class/leds/led1/trigger


Please CC me on any future revisions of this series. I would like to test it.

  reply	other threads:[~2018-07-16  1:00 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-29  5:03 [PATCH v3 1/2] leds: core: Introduce generic pattern interface Baolin Wang
2018-06-29  5:03 ` [PATCH v3 2/2] leds: sc27xx: Add pattern_set/get/clear interfaces for LED controller Baolin Wang
2018-07-11 11:02 ` [PATCH v3 1/2] leds: core: Introduce generic pattern interface Baolin Wang
2018-07-11 21:10   ` Jacek Anaszewski
2018-07-12 12:24     ` Baolin Wang
2018-07-12 21:41       ` Jacek Anaszewski
2018-07-13  1:58         ` Baolin Wang
2018-07-14 21:20       ` Pavel Machek
2018-07-14 22:02         ` Jacek Anaszewski
2018-07-14 22:29           ` Pavel Machek
2018-07-14 22:39             ` Pavel Machek
2018-07-15 12:22               ` Jacek Anaszewski
2018-07-16  1:00                 ` David Lechner [this message]
2018-07-16 20:29                   ` Jacek Anaszewski
2018-07-16 21:56                     ` Pavel Machek
2018-07-17 20:26                       ` Jacek Anaszewski
2018-07-17 21:07                         ` Pavel Machek
2018-07-24  0:35                       ` Bjorn Andersson
2018-07-18  7:56                     ` Pavel Machek
2018-07-18 11:32                       ` Baolin Wang
2018-07-18 12:08                         ` Pavel Machek
2018-07-18 17:00                           ` David Lechner
2018-07-20 19:11                             ` Jacek Anaszewski
2018-07-24  0:55                               ` Bjorn Andersson
2018-07-18 18:54                       ` Jacek Anaszewski
2018-07-18 19:22                         ` Jacek Anaszewski
2018-07-18 22:13                           ` David Lechner
2018-07-18 22:17                           ` Pavel Machek
2018-07-19 20:20                             ` Pavel Machek
2018-07-20 18:08                               ` Jacek Anaszewski
2018-07-23  6:59                               ` Baolin Wang
2018-07-24 11:41                                 ` Pavel Machek
2018-07-27  5:15                                   ` Baolin Wang
2018-07-27  8:36                                     ` Pavel Machek
2018-07-27  8:41                                       ` Baolin Wang
2018-07-24 11:50                                 ` Pavel Machek
2018-07-24  0:18                   ` Bjorn Andersson
2018-07-16 11:08                 ` Baolin Wang

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=2c3a8911-150a-9b25-2a66-a9432047f96b@lechnology.com \
    --to=david@lechnology.com \
    --cc=baolin.wang@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).