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] [day] [month] [year] [list]
Message-ID: <d9f9dd95-b5c4-8447-1391-594b461f805c@gmail.com>
Date:   Tue, 9 May 2017 22:43:45 +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,
        mark.rutland@....com, tony.makkiel@...ri.com, linz@...pro.net,
        robh@...nel.org, romlem@...gle.com, joelaf@...gle.com,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-leds@...r.kernel.org
Subject: Re: [PATCH 0/3] led: ledtrig-transient: add support for hrtimer

On 05/08/2017 11:06 PM, Pavel Machek wrote:
> On Sun 2017-04-30 14:36:58, David Lin 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].
> 
> Yes, and objection still stands: You are misusing LED subsystem for
> vibration motors. We already have support for haptic feedback in input
> subsystem.

Regardless of whether it is a misuse or not (ledtrig-transient
documentation suggests that it is one of use cases) we have to keep
it as it has been around for a long time and it has userspace users [0].

Moreover there seems to be broad consensus about it among kernel
people [1].


[0]
https://android.googlesource.com/platform%2Fhardware%2Flibhardware/+/61701df363310a5cbd95e3e1638baa9526e42c9b
[1] https://patchwork.kernel.org/patch/8664831/

-- 
Best regards,
Jacek Anaszewski

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ