linux-kernel - Re: [PATCH] leds: put hard limit on minimum blink period for slow leds

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: <555AD9B7.1000803@samsung.com>
Date:	Tue, 19 May 2015 08:35:35 +0200
From:	Jacek Anaszewski <j.anaszewski@...sung.com>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	linux-leds@...r.kernel.org,
	Linux kernel <linux-kernel@...r.kernel.org>,
	Stas Sergeev <stsp@...rs.sourceforge.net>,
	Bryan Wu <cooloney@...il.com>,
	Richard Purdie <rpurdie@...ys.net>,
	Michael Hennerich <michael.hennerich@...log.com>,
	Jan-Simon Moeller <jansimon.moeller@....de>,
	Support Opensource <support.opensource@...semi.com>,
	Milo Kim <milo.kim@...com>, Riku Voipio <riku.voipio@....fi>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	patches@...nsource.wolfsonmicro.com
Subject: Re: [PATCH] leds: put hard limit on minimum blink period for slow leds

On 05/18/2015 10:28 AM, Jacek Anaszewski wrote:
> Hi Stas,
>
> On 05/15/2015 06:47 PM, Stas Sergeev wrote:
>>
>> Currently the timer trigger allows to set blink period as small as
>> 1mS. But in fact the minimum period is jiffy, which is usually 10mS.
>> The following mail says:
>> http://lkml.iu.edu/hypermail/linux/kernel/1504.3/03469.html
>> ---
>
> Text after '---' characters is not added to the commit message.
> Please use different characters for this and check how your patch
> looks in git log after applying it locally.
>
>> As I mentioned before even with hr timer it wouldn't be possible
>> to assure that 1ms is achievable due to locking and bus latency
>> reasons.
>> ---
>> So the limit of 10mS should be enforced for drivers that use
>> waiting operations, like transfers across slow bus.
>> This allows to stay on safe side when CONFIG_HZ is set to eg 1000.
>>
>> This patch differentiates the "slow" drivers by marking them with
>> the new LED_BRIGHTNESS_SLOW flag. Currently every driver that uses
>> a work-queue in .brightness_set op, is marked as such.
>> The extra bonus is the possibility of a further development
>> aiming for software PWM for "fast" drivers.

[...]

>> +#define LED_BRIGHTNESS_SLOW    (1 << 24)

I think we'd better add LED_BRIGHTNESS_FAST flag instead.
Then the drivers not using work queue will have to be updated.
It will also indicate what drivers are intended to be the actual
beneficiary of the modification.

-- 
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/