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: <20180824101145.GA1510@amd>
Date:   Fri, 24 Aug 2018 12:11:45 +0200
From:   Pavel Machek <pavel@....cz>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc:     Baolin Wang <baolin.wang@...aro.org>, rteysseyre@...il.com,
        bjorn.andersson@...aro.org, broonie@...nel.org,
        linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/2] leds: core: Introduce LED pattern trigger

Hi!

> I think that it would be more flexible if software pattern fallback
> was applied in case of pattern_set failure. Otherwise, it would
> lead to the situation where LED class devices that support hardware
> blinking couldn't be applied the same set of patterns as LED class
> devices that don't implement pattern_set. The latter will always have to
> resort to using software pattern engine which will accept far greater
> amount of pattern combinations.
> 
> In this case we need to discuss on what basis the decision will be
> made on whether hardware or software engine will be used.
> 
> Possible options coming to mind:
> - an interface will be provided to determine max difference between
>   the settings supported by the hardware and the settings requested by
>   the user, that will result in aligning user's setting to the hardware
>   capabilities
> - the above alignment rate will be predefined instead
> - hardware engine will be used only if user requests supported settings
>   on the whole span of the requested pattern
> - in each of the above cases it would be worth to think of the
>   interface to show the scope of the settings supported by hardware

I'd recommend keeping it simple. We use hardware engine if driver
author thinks pattern is "close enough".

If human can not tell the difference, it probably is.

We may want to do something more formal later.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)