public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: "linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] leds: triggers: add support for RGB triggers
Date: Mon, 21 Mar 2016 16:35:56 +0100	[thread overview]
Message-ID: <56F014DC.7060405@samsung.com> (raw)
In-Reply-To: <56EDA471.1060801@gmail.com>

On 03/19/2016 08:11 PM, Heiner Kallweit wrote:
> Am 18.03.2016 um 14:10 schrieb Jacek Anaszewski:
>> On 03/17/2016 08:53 PM, Heiner Kallweit wrote:
>>> Am 17.03.2016 um 14:41 schrieb Jacek Anaszewski:
>>>> Hi Heiner,
>>>>
>>>> On 03/13/2016 06:14 PM, Heiner Kallweit wrote:
>>>>> Add basic support for RGB triggers. Triggers with flag LED_TRIG_CAP_RGB
>>>>> set are available to RGB LED devices only.
>>>>>
>>>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>>>> ---
>>>>>     drivers/leds/led-triggers.c | 15 ++++++++++++---
>>>>>     include/linux/leds.h        |  3 +++
>>>>>     2 files changed, 15 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
>>>>> index 2181581..3ccf88b 100644
>>>>> --- a/drivers/leds/led-triggers.c
>>>>> +++ b/drivers/leds/led-triggers.c
>>>>> @@ -30,6 +30,13 @@ static LIST_HEAD(trigger_list);
>>>>>
>>>>>      /* Used by LED Class */
>>>>>
>>>>> +static inline bool led_trig_check_rgb(struct led_trigger *trig,
>>>>> +                      struct led_classdev *led_cdev)
>>>>> +{
>>>>> +    return !(trig->flags & LED_TRIG_CAP_RGB) ||
>>>>> +           led_cdev->flags & LED_DEV_CAP_RGB;
>>>>> +}
>>>>
>>>> Could you explain what is the purpose of this function?
>>>> What actually do we want to check here?
>>>>
>>> Triggers using RGB functionality can't be used with non-RGB LED's.
>>> This check checks for such unsupported combinations:
>>> It returns false if the trigger uses RGB functionality but LED doesn't
>>> support the RGB extension.
>>
>> We need more meaningful name for it. Maybe led_trigger_is_supported() ?
>> And let's make it no-op for !CONFIG_LEDS_CLASS_RGB case.
>>
> OK, led_trigger_is_supported() is better.
>
> Making the function a no-op in the non-RGB case would have some impact:
> We'd have to make sure that all public trigger functions are a de-facto no-op
> for RGB triggers (at least register / unregister). Means we would need
> something like this in each public trigger function:
>
> #if !IS_ENABLED(CONFIG_LEDS_CLASS_RGB)
> 	if (trig->flags & LED_TRIG_CAP_RGB))
> 		return;
> #endif
>
> I think this would add a lot of overhead and therefore IMHO it's better to
> not make the check function a no-op.

Wouldn't it suffice to make the no-op returning true?
Preventing RGB trigger registration for non-RGB LED class configuration
seems to be different thing, also to be considered.

>>>>>     ssize_t led_trigger_store(struct device *dev, struct device_attribute *attr,
>>>>>             const char *buf, size_t count)
>>>>>     {
>>>>> @@ -52,12 +59,12 @@ ssize_t led_trigger_store(struct device *dev, struct device_attribute *attr,
>>>>>         down_read(&triggers_list_lock);
>>>>>         list_for_each_entry(trig, &trigger_list, next_trig) {
>>>>>             if (sysfs_streq(buf, trig->name)) {
>>>>> +            if (!led_trig_check_rgb(trig, led_cdev))
>>>>> +                break;
>>>
>>> Check for the case that userspace wants to set a RGB trigger for a non-RGB LED via sysfs.
>>>
>>>>>                 down_write(&led_cdev->trigger_lock);
>>>>>                 led_trigger_set(led_cdev, trig);
>>>>>                 up_write(&led_cdev->trigger_lock);
>>>>> -
>>>>> -            up_read(&triggers_list_lock);
>>>>> -            goto unlock;
>>>>> +            break;
>>
>> This seems to be an unrelated cleanup. Please submit it separately.
>>
> OK
>
>>>>>             }
>>>>>         }
>>>>>         up_read(&triggers_list_lock);
>>>>> @@ -84,6 +91,8 @@ ssize_t led_trigger_show(struct device *dev, struct device_attribute *attr,
>>>>>             len += sprintf(buf+len, "none ");
>>>>>
>>>>>         list_for_each_entry(trig, &trigger_list, next_trig) {
>>>>> +        if (!led_trig_check_rgb(trig, led_cdev))
>>>>> +            continue;
>>>
>>> Omit RGB triggers when listing the available triggers for a non-RGB LED via sysfs.
>>>
>>>>>             if (led_cdev->trigger && !strcmp(led_cdev->trigger->name,
>>>>>                                 trig->name))
>>>>>                 len += sprintf(buf+len, "[%s] ", trig->name);
>>>>> diff --git a/include/linux/leds.h b/include/linux/leds.h
>>>>> index 58e22e6..07eb074 100644
>>>>> --- a/include/linux/leds.h
>>>>> +++ b/include/linux/leds.h
>>>>> @@ -248,6 +248,9 @@ enum led_brightness led_hsv_to_rgb(enum led_brightness hsv);
>>>>>     struct led_trigger {
>>>>>         /* Trigger Properties */
>>>>>         const char     *name;
>>>>> +    u8        flags;
>>>>> +#define LED_TRIG_CAP_RGB    BIT(0)
>>>>> +
>>>>>         void        (*activate)(struct led_classdev *led_cdev);
>>>>>         void        (*deactivate)(struct led_classdev *led_cdev);
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>


-- 
Best regards,
Jacek Anaszewski

  reply	other threads:[~2016-03-21 15:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <56E59FFE.8040203@googlemail.com>
     [not found] ` <56EAB407.60904@samsung.com>
2016-03-17 19:53   ` [PATCH 1/3] leds: triggers: add support for RGB triggers Heiner Kallweit
2016-03-18 13:10     ` Jacek Anaszewski
2016-03-19 19:11       ` Heiner Kallweit
2016-03-21 15:35         ` Jacek Anaszewski [this message]
2016-03-21 17:34           ` Heiner Kallweit
2016-03-22  8:05             ` Jacek Anaszewski
2016-03-22 11:47               ` Heiner Kallweit
2016-03-22 16:00                 ` Jacek Anaszewski
2016-03-22 22:06                   ` Heiner Kallweit
2016-03-23  8:32                     ` Jacek Anaszewski
2016-03-23 11:57                       ` Heiner Kallweit
2016-03-23 16:02                         ` Jacek Anaszewski
2016-03-23 16:36                           ` Heiner Kallweit
2016-03-24 13:23                             ` Jacek Anaszewski
2016-03-24 15:44                               ` Heiner Kallweit
2016-03-24 21:32                                 ` 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=56F014DC.7060405@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox