linux-kernel - Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180724001851.GE30024@minitux>
Date:   Mon, 23 Jul 2018 17:18:51 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     David Lechner <david@...hnology.com>
Cc:     Baolin Wang <baolin.wang@...aro.org>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, Mark Brown <broonie@...nel.org>,
        Linux LED Subsystem <linux-leds@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

On Sun 15 Jul 18:00 PDT 2018, David Lechner wrote:

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

In the case where you describe this as two different LEDs (to Linux) and
you rely on the two enable-calls to happen fairly quickly I think you
can just as well specify the same pattern in two independent triggers.

This also helps by not providing the illusion of there being any
synchronization between them.

Regards,
Bjorn