All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
To: Bryan Wu <cooloney-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Linux LED Subsystem
	<linux-leds-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Kyungmin Park
	<kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	Richard Purdie <rpurdie-Fm38FmjxZ/leoWH0uzbU5w@public.gmane.org>
Subject: Re: [PATCH/RFC v5 2/4] leds: implement sysfs interface locking mechanism
Date: Fri, 12 Sep 2014 08:45:03 +0200	[thread overview]
Message-ID: <5412966F.9000309@samsung.com> (raw)
In-Reply-To: <CAK5ve-+Trcg+ZL5gBZmpY_Zcqk5VOhP7jowS8Liqcz0pO_UbBQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi Bryan,

Thanks for a review.

On 09/12/2014 03:11 AM, Bryan Wu wrote:
> On Wed, Aug 20, 2014 at 6:41 AM, Jacek Anaszewski
> <j.anaszewski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>> Add a mechanism for locking LED subsystem sysfs interface.
>> This patch prepares ground for addition of LED Flash Class
>> extension, whose API will be integrated with V4L2 Flash API.
>> Such a fusion enforces introducing a locking scheme, which
>> will secure consistent access to the LED Flash Class device.
>>
>> The mechanism being introduced allows for disabling LED
>> subsystem sysfs interface by calling led_sysfs_lock function
>> and enabling it by calling led_sysfs_unlock. The functions
>> alter the LED_SYSFS_LOCK flag state and must be called
>> under mutex lock. The state of the lock is checked with use
>> of led_sysfs_is_locked function. Such a design allows for
>> providing immediate feedback to the user space on whether
>> the LED Flash Class device is available or is under V4L2 Flash
>> sub-device control.
>>
>> Signed-off-by: Jacek Anaszewski <j.anaszewski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> Acked-by: Kyungmin Park <kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> Cc: Bryan Wu <cooloney-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: Richard Purdie <rpurdie-Fm38FmjxZ/leoWH0uzbU5w@public.gmane.org>
>> ---
>>   drivers/leds/led-class.c    |   23 ++++++++++++++++++++---
>>   drivers/leds/led-core.c     |   18 ++++++++++++++++++
>>   drivers/leds/led-triggers.c |   15 ++++++++++++---
>>   include/linux/leds.h        |   32 ++++++++++++++++++++++++++++++++
>>   4 files changed, 82 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
>> index 6f82a76..0bc0ba9 100644
>> --- a/drivers/leds/led-class.c
>> +++ b/drivers/leds/led-class.c
>> @@ -39,17 +39,31 @@ static ssize_t brightness_store(struct device *dev,
>>   {
>>          struct led_classdev *led_cdev = dev_get_drvdata(dev);
>>          unsigned long state;
>> -       ssize_t ret = -EINVAL;
>> +       ssize_t ret;
>> +
>> +#ifdef CONFIG_V4L2_FLASH_LED_CLASS
>
> Can we remove this #ifdef? Following code looks good to the common LED class.

Sure.

>> +       mutex_lock(&led_cdev->led_lock);
>
> Can we choose more meaningful name instead of led_lock here?
> Then use led_sysfs_enable() instead of led_sysfs_unlock()
> led_sysfs_disable instead of led_sysfs_lock()
> led_sysfs_is_disabled instead of led_sysfs_is_locked()
>
> And the flag LED_SYSFS_LOCK -> LED_SYSFS_DISABLE
>
> I was just confused by the name lock and unlock and mutex lock.
>
> The idea looks good to me.

Indeed, this naming will be more intuitive.

Regards,
Jacek

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Bryan Wu <cooloney@gmail.com>
Cc: Linux LED Subsystem <linux-leds@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	b.zolnierkie@samsung.com, Richard Purdie <rpurdie@rpsys.net>
Subject: Re: [PATCH/RFC v5 2/4] leds: implement sysfs interface locking mechanism
Date: Fri, 12 Sep 2014 08:45:03 +0200	[thread overview]
Message-ID: <5412966F.9000309@samsung.com> (raw)
In-Reply-To: <CAK5ve-+Trcg+ZL5gBZmpY_Zcqk5VOhP7jowS8Liqcz0pO_UbBQ@mail.gmail.com>

Hi Bryan,

Thanks for a review.

On 09/12/2014 03:11 AM, Bryan Wu wrote:
> On Wed, Aug 20, 2014 at 6:41 AM, Jacek Anaszewski
> <j.anaszewski@samsung.com> wrote:
>> Add a mechanism for locking LED subsystem sysfs interface.
>> This patch prepares ground for addition of LED Flash Class
>> extension, whose API will be integrated with V4L2 Flash API.
>> Such a fusion enforces introducing a locking scheme, which
>> will secure consistent access to the LED Flash Class device.
>>
>> The mechanism being introduced allows for disabling LED
>> subsystem sysfs interface by calling led_sysfs_lock function
>> and enabling it by calling led_sysfs_unlock. The functions
>> alter the LED_SYSFS_LOCK flag state and must be called
>> under mutex lock. The state of the lock is checked with use
>> of led_sysfs_is_locked function. Such a design allows for
>> providing immediate feedback to the user space on whether
>> the LED Flash Class device is available or is under V4L2 Flash
>> sub-device control.
>>
>> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> Cc: Bryan Wu <cooloney@gmail.com>
>> Cc: Richard Purdie <rpurdie@rpsys.net>
>> ---
>>   drivers/leds/led-class.c    |   23 ++++++++++++++++++++---
>>   drivers/leds/led-core.c     |   18 ++++++++++++++++++
>>   drivers/leds/led-triggers.c |   15 ++++++++++++---
>>   include/linux/leds.h        |   32 ++++++++++++++++++++++++++++++++
>>   4 files changed, 82 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
>> index 6f82a76..0bc0ba9 100644
>> --- a/drivers/leds/led-class.c
>> +++ b/drivers/leds/led-class.c
>> @@ -39,17 +39,31 @@ static ssize_t brightness_store(struct device *dev,
>>   {
>>          struct led_classdev *led_cdev = dev_get_drvdata(dev);
>>          unsigned long state;
>> -       ssize_t ret = -EINVAL;
>> +       ssize_t ret;
>> +
>> +#ifdef CONFIG_V4L2_FLASH_LED_CLASS
>
> Can we remove this #ifdef? Following code looks good to the common LED class.

Sure.

>> +       mutex_lock(&led_cdev->led_lock);
>
> Can we choose more meaningful name instead of led_lock here?
> Then use led_sysfs_enable() instead of led_sysfs_unlock()
> led_sysfs_disable instead of led_sysfs_lock()
> led_sysfs_is_disabled instead of led_sysfs_is_locked()
>
> And the flag LED_SYSFS_LOCK -> LED_SYSFS_DISABLE
>
> I was just confused by the name lock and unlock and mutex lock.
>
> The idea looks good to me.

Indeed, this naming will be more intuitive.

Regards,
Jacek


  parent reply	other threads:[~2014-09-12  6:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-20 13:41 [PATCH/RFC v5 0/4] LED / flash API integration - LED Flash Class Jacek Anaszewski
2014-08-20 13:41 ` Jacek Anaszewski
2014-08-20 13:41 ` [PATCH/RFC v5 1/4] leds: Improve and export led_update_brightness Jacek Anaszewski
2014-09-05 21:03   ` Bryan Wu
2014-09-12 21:05     ` Bryan Wu
2014-08-20 13:41 ` [PATCH/RFC v5 2/4] leds: implement sysfs interface locking mechanism Jacek Anaszewski
2014-09-12  1:11   ` Bryan Wu
     [not found]     ` <CAK5ve-+Trcg+ZL5gBZmpY_Zcqk5VOhP7jowS8Liqcz0pO_UbBQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-12  6:45       ` Jacek Anaszewski [this message]
2014-09-12  6:45         ` Jacek Anaszewski
2014-08-20 13:41 ` [PATCH/RFC v5 3/4] leds: add API for setting torch brightness Jacek Anaszewski
2014-08-20 13:41 ` [PATCH/RFC v5 4/4] leds: Add LED Flash Class wrapper to LED subsystem Jacek Anaszewski

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=5412966F.9000309@samsung.com \
    --to=j.anaszewski-sze3o3uu22jbdgjk7y7tuq@public.gmane.org \
    --cc=b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=cooloney-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-leds-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rpurdie-Fm38FmjxZ/leoWH0uzbU5w@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.