linux-kernel - Re: [PATCH v5 1/2] leds: core: Introduce LED pattern trigger

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: <20180828204749.GH2523@minitux>
Date:   Tue, 28 Aug 2018 13:47:49 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Baolin Wang <baolin.wang@...aro.org>
Cc:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, rteysseyre@...il.com,
        Mark Brown <broonie@...nel.org>,
        Linux LED Subsystem <linux-leds@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 1/2] leds: core: Introduce LED pattern trigger

On Sat 25 Aug 00:51 PDT 2018, Baolin Wang wrote:

> On 25 August 2018 at 04:44, Jacek Anaszewski <jacek.anaszewski@...il.com> wrote:
> > On 08/24/2018 10:12 PM, Pavel Machek wrote:
> >> On Fri 2018-08-24 21:49:50, Jacek Anaszewski wrote:
> >>> Hi Pavel,
> >>>
> >>> On 08/24/2018 12:11 PM, Pavel Machek wrote:
[..]
> >>> +    if (led_cdev->pattern_set) {
> >>> +            return led_cdev->pattern_set(led_cdev, data->patterns,
> >>> +                                         data->npatterns, data->repeat);
> >>> +    }
> >>
> >> Yeah, that sounds wrong. (Sorry I did not pay enough attention).
> >>
> >> It pattern_set() returns special error code, it should just continue
> >> and use software pattern fallback.
> >
> > And now we can get back to the issue I was concerned about in the
> > email you replied to, i.e. what series of [brightness delta_t] tuples
> > should be written to the pattern file to enable hardware breathing
> > engine.
> 
> OK. So now we've made a consensus to use the software pattern fallback
> if failed to set hardware pattern. How about introduce one interface
> to convert hardware patterns to software patterns if necessary?
> 

I do not agree that a silent fallback mechanism is the way to go here.
There is a enormous difference in power consumption between letting a
dedicated piece of hardware drive a pulse on a LED or using a general
purpose ARM core running at hundreds of MHz.


Note that the most common use case for the driver I'm trying to upstream
is to pulse the LED when you have a notification pending on your Android
device, in which case you want all the CPUs are completely powered down.

Regards,
Bjorn