linux-kernel - Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

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: <9c75c3a9-4123-c7f3-7725-45ba752d672a@gmail.com>
Date:   Thu, 14 Sep 2017 21:31:31 +0200
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Pavel Machek <pavel@....cz>, David Lin <dtwlin@...gle.com>
Cc:     corbet@....net, rpurdie@...ys.net, hdegoede@...hat.com,
        gregkh@...uxfoundation.org, robh@...nel.org, romlem@...gle.com,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-leds@...r.kernel.org
Subject: Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

Hi David and Pavel,

On 09/13/2017 10:20 PM, Pavel Machek wrote:
> Hi!
> 
>> These patch series add the LED_BRIGHTNESS_FAST flag support for
>> ledtrig-transient to use hrtimer so that platforms with high-resolution timer
>> support can have better accuracy in the trigger duration timing. The need for
>> this support is driven by the fact that Android has removed the timed_ouput [1]
>> and is now using led-trigger for handling vibrator control which requires the
>> timer to be accurate up to a millisecond. However, this flag support would also
>> allow hrtimer to co-exist with the ktimer without causing warning to the
>> existing drivers [2].
> 
> NAK.
> 
> LEDs do not need extra overhead, and vibrator control should not go
> through LED subsystem.
> 
> Input subsystem includes support for vibrations and force
> feedback. Please use that instead.

I think that most vital criterion here is the usability of the
interface. If it can be harnessed for doing the work seemingly
unrelated to the primary subsystem's purpose, that's fine.
Moreover, it is extremely easy to use in comparison to the force
feedback one.

I would change one more thing in this patch, though. The hr_timer engine
should be made optional and not used by default for fast LEDs.
It could be made configurable by exposing additional sysfs file from
ledtrig-transient.c, e.g. hr_timer_support, accepting boolean value.

-- 
Best regards,
Jacek Anaszewski