linux-kernel - Re: [PATCH/RFC v4 06/21] leds: add API for setting torch brightness

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:	Thu, 17 Jul 2014 00:54:44 +0300
From:	Sakari Ailus <sakari.ailus@....fi>
To:	Jacek Anaszewski <j.anaszewski@...sung.com>,
	linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:	kyungmin.park@...sung.com, b.zolnierkie@...sung.com,
	Bryan Wu <cooloney@...il.com>,
	Richard Purdie <rpurdie@...ys.net>
Subject: Re: [PATCH/RFC v4 06/21] leds: add API for setting torch brightness

Hi Jacek,

Jacek Anaszewski wrote:
...
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 1a130cc..9bea9e6 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -44,11 +44,21 @@ struct led_classdev {
>   #define LED_BLINK_ONESHOT_STOP	(1 << 18)
>   #define LED_BLINK_INVERT	(1 << 19)
>   #define LED_SYSFS_LOCK		(1 << 20)
> +#define LED_DEV_CAP_TORCH	(1 << 21)
>
>   	/* Set LED brightness level */
>   	/* Must not sleep, use a workqueue if needed */
>   	void		(*brightness_set)(struct led_classdev *led_cdev,
>   					  enum led_brightness brightness);
> +	/*
> +	 * Set LED brightness immediately - it is required for flash led
> +	 * devices as they require setting torch brightness to have immediate
> +	 * effect. brightness_set op cannot be used for this purpose because
> +	 * the led drivers schedule a work queue task in it to allow for
> +	 * being called from led-triggers, i.e. from the timer irq context.
> +	 */

Do we need to classify actual devices based on this? I think it's rather 
a different API behaviour between the LED and the V4L2 APIs.

On devices that are slow to control, the behaviour should be asynchronous
over the LED API and synchronous when accessed through the V4L2 API. How
about implementing the work queue, as I have suggested, in the framework, so
that individual drivers don't need to care about this and just implement the
synchronous variant of this op? A flag could be added to distinguish devices
that are fast so that the work queue isn't needed.

It'd be nice to avoid individual drivers having to implement multiple ops to
do the same thing, just for differing user space interfacs.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@....fi     XMPP: sailus@...iisi.org.uk
--
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/