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  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]
Date:   Mon, 18 Sep 2017 22:43:40 +0200
From:   Jacek Anaszewski <>
To:     Pavel Machek <>
Cc:, David Lin <>,,,,,,,,,
Subject: Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:
 ledtrig-transient: add support for hrtimer


On 09/17/2017 07:50 PM, Pavel Machek wrote:
> Hi!
>>>> Do you think such an improvement could be harmful in some way,
>>>> even if it was made optional?
>>> Of course, we can make LED timing accurate down to microseconds. It will
>>> mean increased overhead -- for "improvement" human can not perceive.
>>> If someone has problems with LED delays not being accurate enough... we
>>> may want to fix it. But that is not the case here, is it?
>> AFAIR David was mentioning that the hr_timer support is perceivable
> He said that hr_timer support is perceivable _when he is driving
> vibration motor_. Which he should not do in the first place.
> Yes, if the difference is perceivable with LED in non-crazy
> configuration (*), we can take the patch. Is it? Do we have someone
> not from Google observing it?
> 									Pavel
> (*) emulating PWM using blink trigger counts as "crazy" :-)

How about adding CONFIG_LED_TRIGGERS_HR_TIMER_SUPPORT, guarding the
hr timer support in triggers (timer trigger could also benefit from it)
with it, and adding "(EXPERIMENTAL)" tag to the config description?

Best regards,
Jacek Anaszewski

Powered by blists - more mailing lists