linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org,
	sakari.ailus@linux.intel.com, stsp@users.sourceforge.net,
	pavel@ucw.cz, ospite@studenti.unina.it, davem@davemloft.net,
	linus.walleij@linaro.org, ricardo.ribalda@gmail.com,
	p.meerwald@bct-electronic.com
Subject: Re: [PATCH 3/5] leds: Rename brightness_set_sync op to brightness_set_blocking
Date: Wed, 23 Sep 2015 11:34:07 +0200	[thread overview]
Message-ID: <5602720F.7080405@samsung.com> (raw)
In-Reply-To: <5602648D.9040609@samsung.com>

On 09/23/2015 10:36 AM, Jacek Anaszewski wrote:
> On 09/22/2015 08:54 PM, Andrew Lunn wrote:
>> On Wed, Sep 16, 2015 at 12:47:42PM +0200, Jacek Anaszewski wrote:
>>> The initial purpose of brightness_set_sync op, introduced along with
>>> the LED flash class extension, was to add a means for setting torch LED
>>> brightness as soon as possible, which couldn't have been guaranteed by
>>> brightness_set op. This patch renames the op to brightness_set_blocking,
>>> which describes its purpose in a more generic way, and is beneficial
>>> in view of the prospective changes in the core related to using
>>> LED core's set_brightness_work for setting brightness for LED class
>>> drivers that can sleep or use delays while setting brightness.
>>
>> ...
>>
>>> -    /*
>>> -     * Set LED brightness level immediately - it can block the
>>> caller for
>>> -     * the time required for accessing a LED device register.
>>> -     */
>>> -    int        (*brightness_set_sync)(struct led_classdev *led_cdev,
>>> -                    enum led_brightness brightness);
>>> +    /* Can sleep or use delays */
>>> +    int (*brightness_set_blocking)(struct led_classdev *led_cdev,
>>
>> I'm no expert when it comes to flash photography with digital
>> cameras.
>
> This op is now not specific to flash LEDs. The last sentence in the
> commit message explains this, but now I see that it is too long.
> Let's change it to:
>
> "This patch renames the op to brightness_set_blocking,
> which describes its purpose in a more generic way. It is beneficial
> in view of the prospective changes in the LED core, aiming at removing
> the need for using work queues in LED class drivers that can sleep
> or use delays while setting brightness."
>
>> But to me the old comment seems better.
>
> I changed it to highlight the essence of how it differs from
> brightness_set.
>
>> Doesn't the caller
>> want to know the flash is now giving out light?
>
> We have strobe_get op for this, but it is in led-class-flash extension.
> This is irrelevant here.

I focused myself on flash mode of flash LED, but you asked
probably about brightness in torch mode, which can be obtained
with brightness_get op, if implemented by the driver.


-- 
Best Regards,
Jacek Anaszewski

  reply	other threads:[~2015-09-23  9:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-16 10:47 [PATCH 0/5] LED core improvements Jacek Anaszewski
2015-09-16 10:47 ` [PATCH 1/5] leds: core: Move LED core callbacks out of led-class.c Jacek Anaszewski
2015-09-22 19:06   ` Andrew Lunn
2015-10-06 15:31   ` Pavel Machek
2015-10-07  7:29     ` Jacek Anaszewski
2015-09-16 10:47 ` [PATCH 2/5] leds: core: Add LED_BLINK_CHANGE and LED_BLINK_DISABLE flags Jacek Anaszewski
2015-09-22 18:44   ` Andrew Lunn
2015-09-23  8:07     ` Jacek Anaszewski
2015-10-06 15:35   ` Pavel Machek
2015-09-16 10:47 ` [PATCH 3/5] leds: Rename brightness_set_sync op to brightness_set_blocking Jacek Anaszewski
2015-09-22 18:54   ` Andrew Lunn
2015-09-23  8:36     ` Jacek Anaszewski
2015-09-23  9:34       ` Jacek Anaszewski [this message]
2015-10-06 15:36   ` Pavel Machek
2015-09-16 10:47 ` [PATCH 4/5] leds: core: Add an internal led_set_brightness_nosleep function Jacek Anaszewski
2015-09-22 19:02   ` Andrew Lunn
2015-09-23  8:53     ` Jacek Anaszewski
2015-09-16 10:47 ` [PATCH 5/5] leds: core: Use set_brightness_work for the blocking op Jacek Anaszewski
2015-09-22  8:03   ` Sakari Ailus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5602720F.7080405@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=ospite@studenti.unina.it \
    --cc=p.meerwald@bct-electronic.com \
    --cc=pavel@ucw.cz \
    --cc=ricardo.ribalda@gmail.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=stsp@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).