linux-kernel - Re: [PATCH] led: ledtrig-transient: replace timer

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: <CAPzFB+XPO4rW58tksTah1j3mLHOBaLi4EECnNiO5kZqPsT356w@mail.gmail.com>
Date:   Wed, 26 Apr 2017 20:48:09 -0700
From:   David Lin <dtwlin@...gle.com>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc:     rpurdie@...ys.net, pavel@....cz, robh@...nel.org,
        Rom Lemarchand <romlem@...gle.com>,
        Joel Fernandes <joelaf@...gle.com>, stable@...r.kernel.org,
        linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer

On Tue, Apr 25, 2017 at 1:15 PM, Jacek Anaszewski
<jacek.anaszewski@...il.com> wrote:
>> However, there's a need to
>> support hrtimer if the LED subsystem claims support the use case of
>> vibrator (please see Documentation/leds/ledtrig-transient.txt) as even
>> a 5ms of variation is perceivable to the user. I'm thinking if a
>> better interim solution is to introduce a
>> LEDS_TRIGGER_TRANSIENT_HRTIMER config to work with both timers in
>> compile time. Would you agree?
>
> I think that it would be better if LED class driver set a flag
> marking itself as capable of setting brightness with high rate.
> I'd limit that only to leds-gpio and devices driven through
> memory mapped registers.
>
> Having the flag e.g. LED_BRIGHTNESS_FAST, we could add support for
> hr timers also to ledtrig-timer.

Can I resubmit the patch implementing LED_BRIGHTNESS_FAST using hrtimer?

>
> You can try also the other option mentioned by Pavel in [1].

Thanks, Pavel. It does look like that input-ff is a more appropriate
subsystem for implementing a vibrator/haptics driver. It also seems
that it's relying on the userspace to control the timing of the
play/stop events which is likely to be less accurate than a hrtimer in
the kernel. But it provides more effect control than the LED
subsystem.