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, 13 Aug 2015 16:15:47 +0200
From:	Andrew Lunn <andrew@...n.ch>
To:	Jacek Anaszewski <j.anaszewski@...sung.com>
Cc:	linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org,
	cooloney@...il.com, rpurdie@...ys.net, stsp@...rs.sourceforge.net,
	Sakari Ailus <sakari.ailus@...ux.intel.com>,
	Pavel Machek <pavel@....cz>
Subject: Re: [PATCH/RFC v5 01/57] leds: Add brightness_set_nonblocking op

On Tue, Aug 11, 2015 at 11:37:14AM +0200, Jacek Anaszewski wrote:
> This patch adds a new brightness_set_nonblocking op to the LED subsystem.
> The op is intended for drivers that set brightness in a non-blocking way,
> i.e. they neither sleep nor use delays while setting brightness.
> 
> Signed-off-by: Jacek Anaszewski <j.anaszewski@...sung.com>
> Cc: Bryan Wu <cooloney@...il.com>
> Cc: Andrew Lunn <andrew@...n.ch>
> Cc: Sakari Ailus <sakari.ailus@...ux.intel.com>
> Cc: Pavel Machek <pavel@....cz>
> Cc: Stas Sergeev <stsp@...rs.sourceforge.net>
> ---
>  include/linux/leds.h |    3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index b122eea..c32f1b8 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -53,6 +53,9 @@ struct led_classdev {
>  	/* Must not sleep, use a workqueue if needed */
>  	void		(*brightness_set)(struct led_classdev *led_cdev,
>  					  enum led_brightness brightness);
> +	/* Intended for drivers that set brightness in a non-blocking way */
> +	void (*brightness_set_nonblocking)(struct led_classdev *led_cdev,
> +					  enum led_brightness brightness);

Hi Jacek

>From an API design point of view, i'm not sure this is the best way to
go. You now have two calls which do the same thing, with the plan that
you want to invert the meaning of brightness_set, the old well known
API call, sometime later. This inverting the meaning is going to catch
people out and introduce bugs.

I would rather add a brightness_set_blocking op. Then as you go
thought the drivers stripping out the work queue, move the driver to
use this brightness_set_blocking.

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