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]
Date:	Mon, 12 Jan 2015 09:04:28 +0100
From:	Jacek Anaszewski <j.anaszewski@...sung.com>
To:	Pavel Machek <pavel@....cz>
Cc:	linux-leds@...r.kernel.org, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	kyungmin.park@...sung.com, b.zolnierkie@...sung.com,
	cooloney@...il.com, rpurdie@...ys.net, sakari.ailus@....fi,
	s.nawrocki@...sung.com
Subject: Re: [PATCH/RFC v10 02/19] Documentation: leds: Add description of LED
 Flash class extension

Hi Pavel,

Thanks for the review.

On 01/09/2015 06:40 PM, Pavel Machek wrote:
> Hi!
>
>> The documentation being added contains overall description of the
>> LED Flash Class and the related sysfs attributes.
>>
>> Signed-off-by: Jacek Anaszewski <j.anaszewski@...sung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@...sung.com>
>> Cc: Bryan Wu <cooloney@...il.com>
>> Cc: Richard Purdie <rpurdie@...ys.net>
>
>> +In order to enable support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol
>> +must be defined in the kernel config. A flash LED driver must register
>> +in the LED subsystem with led_classdev_flash_register function to gain flash
>> +related capabilities.
>> +
>> +There are flash LED devices which can control more than one LED and allow for
>> +strobing the sub-leds synchronously. A LED will be strobed synchronously with
>> +the one whose identifier is written to the flash_sync_strobe sysfs attribute.
>> +The list of available sub-led identifiers can be read from the
>
> sub-LED?

Indeed, this naming will be more consistent.

>> +	- flash_fault - bitmask of flash faults that may have occurred
>> +			possible flags are:
>> +		* 0x01 - flash controller voltage to the flash LED has exceeded
>> +			 the limit specific to the flash controller
>> +		* 0x02 - the flash strobe was still on when the timeout set by
>> +			 the user has expired; not all flash controllers may
>> +			 set this in all such conditions
>> +		* 0x04 - the flash controller has overheated
>> +		* 0x08 - the short circuit protection of the flash controller
>> +			 has been triggered
>> +		* 0x10 - current in the LED power supply has exceeded the limit
>> +			 specific to the flash controller
>> +		* 0x20 - the flash controller has detected a short or open
>> +			 circuit condition on the indicator LED
>> +		* 0x40 - flash controller voltage to the flash LED has been
>> +			 below the minimum limit specific to the flash
>> +		* 0x80 - the input voltage of the flash controller is below
>> +			 the limit under which strobing the flash at full
>> +			 current will not be possible. The condition persists
>> +			 until this flag is no longer set
>> +		* 0x100 - the temperature of the LED has exceeded its allowed
>> +			  upper limit
>
> Did not everyone agree that text strings are preferable to bitmasks?
>
> 									Pavel
>

I just forgot to update the flash_fault documentation. Will fix in the
next version.

-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ