Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754108AbbHNH57 (ORCPT ); Fri, 14 Aug 2015 03:57:59 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:64311 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751255AbbHNH55 (ORCPT ); Fri, 14 Aug 2015 03:57:57 -0400 X-AuditID: cbfec7f5-f794b6d000001495-c0-55cd9f821f94 Message-id: <55CD9F7F.4020706@samsung.com> Date: Fri, 14 Aug 2015 09:57:51 +0200 From: Jacek Anaszewski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-version: 1.0 To: Andrew Lunn Cc: linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org, cooloney@gmail.com, rpurdie@rpsys.net, stsp@users.sourceforge.net, Sakari Ailus , Pavel Machek Subject: Re: [PATCH/RFC v5 01/57] leds: Add brightness_set_nonblocking op References: <1439285890-27329-1-git-send-email-j.anaszewski@samsung.com> <1439285890-27329-2-git-send-email-j.anaszewski@samsung.com> <20150813141547.GB32484@lunn.ch> In-reply-to: <20150813141547.GB32484@lunn.ch> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsVy+t/xq7pN88+GGvxfY25x/u4hZoujOycy WVzeNYfNYuubdYwWd08dZbPYvespq8WnLd+YLDr7prE4cHjsnHWX3WPeyUCPnTs+M3nsmf+D 1WPF6u/sHk2n2lk9Pm+SC2CP4rJJSc3JLEst0rdL4MrYte4Ke8Fc0YquWwuZGhinCHYxcnJI CJhILDt5jBHCFpO4cG89WxcjF4eQwFJGieXrt0M5zxglFnz7BFbFK6AlcX9aAwuIzSKgKjH9 xg+wOJuAocTPF6+ZQGxRgQiJP6f3sULUC0r8mHwPrF5EQEFiysk/rCBDmQXOMkrsefEJrEFY wFPi24wl7BDbVjFKdCw+zAaS4BTQlWg59wtsA7OAtcTKSdugbHmJzWveMk9gFJiFZMksJGWz kJQtYGRexSiaWppcUJyUnmukV5yYW1yal66XnJ+7iRESB193MC49ZnWIUYCDUYmH16LtbKgQ a2JZcWXuIUYJDmYlEd4beUAh3pTEyqrUovz4otKc1OJDjNIcLErivDN3vQ8REkhPLEnNTk0t SC2CyTJxcEo1MJbev/Nmb0eP4wOb0K19UfsrHvi5VWb4HHzMUXuUmddyv9PnhcuEojJMv0h+ YHVdcr5O80xw9X0mx6AV311VX+fWdv1gDnewEU/ZGDe7s4ft0C+TjbsYVOSc3v9YsiZ/gRbz D9Wmt0/nqgmlF1tNYZZlrdtVcOjj6UuPgoM91H9d49LR8ZsnrsRSnJFoqMVcVJwIAC174C9/ AgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2899 Lines: 68 H Andrew, On 08/13/2015 04:15 PM, Andrew Lunn wrote: > 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 >> Cc: Bryan Wu >> Cc: Andrew Lunn >> Cc: Sakari Ailus >> Cc: Pavel Machek >> Cc: Stas Sergeev >> --- >> 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. There are around 60 drivers in the other kernel subsystems that register LED class devices. If we chose the way you proposed then we would have to adjust all of them to the LED core changes, which could complicate the situation during merge window if there were other modifications in the affected drivers. With my approach all old-fashion drivers will be treated by the LED core in the old-fashion way. This is why I introduced LED_BRIGHTNESS_BLOCKING flag - only drivers aware of the LED core changes will set it, which will allow for the LED core to find out which drivers are aware of brightness_set semantics change and implement the op accordingly. This way the change of brightness_set semantics will not be painful. After all drivers across all subsystems are adapted to the LED core changes the flag will be made redundant and we will remove it. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/