From: Rong Zhang <i@rong.moe>
To: Lee Jones <lee@kernel.org>
Cc: "Pavel Machek" <pavel@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"Thomas Weißschuh" <linux@weissschuh.net>,
"Benson Leung" <bleung@chromium.org>,
"Guenter Roeck" <groeck@chromium.org>,
"Marek Behún" <kabel@kernel.org>,
"Mark Pearson" <mpearson-lenovo@squebb.ca>,
"Derek J. Clark" <derekjohn.clark@gmail.com>,
"Hans de Goede" <hansg@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Ike Panhc" <ikepanhc@gmail.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"Jakub Kicinski" <kuba@kernel.org>,
"Vishnu Sankar" <vishnuocv@gmail.com>,
"Vishnu Sankar" <vsankar@lenovo.com>,
linux-leds@vger.kernel.org, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
chrome-platform@lists.linux.dev,
platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH v7 02/13] leds: trigger: Move led_trigger_is_hw_controlled() to the right place
Date: Thu, 24 Sep 2026 19:45:55 +0800 [thread overview]
Message-ID: <577cdb9848906b6b2efcfaff2d68f5ef9a769ae9.camel@rong.moe> (raw)
In-Reply-To: <20260924083709.GA331088@google.com>
Hi Lee,
Thanks for your review.
On Thu, 2026-09-24 at 09:37 +0100, Lee Jones wrote:
> --- checkpatch.pl: clean (0 issues) ---
>
> On Mon, 21 Sep 2026, Rong Zhang wrote:
>
> > Currently led_trigger_is_hw_controlled() is placed at led-class.c, which
> > is not an right place as it falls into the triggers namespace and does
> > triggers stuff.
> >
> > Move it into led-triggers.c, and split it into locked and unlocked
> > variant for convenience.
> >
> > Fixes: b819dc7d8fb2 ("leds: core: Report ENODATA for brightness of hardware controlled LED")
> > Acked-by: Ike Panhc <ikepanhc@gmail.com>
> > Signed-off-by: Rong Zhang <i@rong.moe>
> > ---
> > Changes in v3:
> > - New patch in the series, the dependency of the following patches
> > ---
> > drivers/leds/led-class.c | 10 ----------
> > drivers/leds/led-triggers.c | 19 +++++++++++++++++++
> > include/linux/leds.h | 8 ++++++++
> > 3 files changed, 27 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> > index 4259533dafa1..7110bfbe3b83 100644
> > --- a/drivers/leds/led-class.c
> > +++ b/drivers/leds/led-class.c
> > @@ -27,16 +27,6 @@ static LIST_HEAD(leds_lookup_list);
> >
> > static struct workqueue_struct *leds_wq;
> >
> > -static bool led_trigger_is_hw_controlled(struct led_classdev *led_cdev)
> > -{
> > -#ifdef CONFIG_LEDS_TRIGGERS
> > - guard(rwsem_read)(&led_cdev->trigger_lock);
> > - return led_cdev->trigger && led_cdev->trigger->trigger_type;
> > -#else
> > - return false;
> > -#endif
> > -}
> > -
> > static ssize_t brightness_show(struct device *dev,
> > struct device_attribute *attr, char *buf)
> > {
> > diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
> > index b1223218bda1..bf2543538ed0 100644
> > --- a/drivers/leds/led-triggers.c
> > +++ b/drivers/leds/led-triggers.c
> > @@ -7,9 +7,11 @@
> > * Author: Richard Purdie <rpurdie@openedhand.com>
> > */
> >
> > +#include <linux/cleanup.h>
> > #include <linux/export.h>
> > #include <linux/kernel.h>
> > #include <linux/list.h>
> > +#include <linux/lockdep.h>
> > #include <linux/spinlock.h>
> > #include <linux/device.h>
> > #include <linux/timer.h>
> > @@ -33,6 +35,23 @@ trigger_relevant(struct led_classdev *led_cdev, struct led_trigger *trig)
> > return !trig->trigger_type || trig->trigger_type == led_cdev->trigger_type;
> > }
> >
> > +static bool __led_trigger_is_hw_controlled(struct led_classdev *led_cdev)
> > +{
> > + lockdep_assert_held(&led_cdev->trigger_lock);
> > +
> > + if (!led_cdev->trigger)
> > + return false;
> > +
> > + return led_cdev->trigger->trigger_type;
>
> How does this not cause a compiler warning?
trigger_type is a pointer. Implicitly converting a pointer to boolean via
a return statement is completely valid in C11.
6.3.1.2 Boolean type
When any scalar value is converted to _Bool, the result is 0 if the value
compares equal to 0; otherwise, the result is 1.
6.8.6.4 The return statement
...If the expression has a type different from the return type of the
function in which it appears, the value is converted as if by
assignment to an object having the return type of the function.
>
> This needs to be evaluated properly.
If it's preferred to make the intention clearer, how about:
return led_cdev->trigger->trigger_type != NULL;
Thanks,
Rong
>
> > +}
> > +
> > +bool led_trigger_is_hw_controlled(struct led_classdev *led_cdev)
> > +{
> > + guard(rwsem_read)(&led_cdev->trigger_lock);
> > + return __led_trigger_is_hw_controlled(led_cdev);
> > +}
> > +EXPORT_SYMBOL_GPL(led_trigger_is_hw_controlled);
> > +
> > ssize_t led_trigger_write(struct file *filp, struct kobject *kobj,
> > const struct bin_attribute *bin_attr, char *buf,
> > loff_t pos, size_t count)
> > diff --git a/include/linux/leds.h b/include/linux/leds.h
> > index a515f075c29a..46ad2e03e1c6 100644
> > --- a/include/linux/leds.h
> > +++ b/include/linux/leds.h
> > @@ -534,6 +534,8 @@ void led_trigger_set_default(struct led_classdev *led_cdev);
> > int led_trigger_set(struct led_classdev *led_cdev, struct led_trigger *trigger);
> > void led_trigger_remove(struct led_classdev *led_cdev);
> >
> > +bool led_trigger_is_hw_controlled(struct led_classdev *led_cdev);
> > +
> > static inline void led_set_trigger_data(struct led_classdev *led_cdev,
> > void *trigger_data)
> > {
> > @@ -584,6 +586,12 @@ static inline int led_trigger_set(struct led_classdev *led_cdev,
> > }
> >
> > static inline void led_trigger_remove(struct led_classdev *led_cdev) {}
> > +
> > +static inline bool led_trigger_is_hw_controlled(struct led_classdev *led_cdev)
> > +{
> > + return false;
> > +}
> > +
> > static inline void led_set_trigger_data(struct led_classdev *led_cdev) {}
> > static inline void *led_get_trigger_data(struct led_classdev *led_cdev)
> > {
> >
> > --
> > 2.55.0
> >
next prev parent reply other threads:[~2026-09-24 11:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 19:40 [PATCH v7 00/13] leds: Add support for hardware-initiated hardware control trigger transition Rong Zhang
2026-09-20 19:40 ` [PATCH v7 01/13] leds: class: Always protect brightness_show() with led_access Rong Zhang
2026-09-20 19:40 ` [PATCH v7 02/13] leds: trigger: Move led_trigger_is_hw_controlled() to the right place Rong Zhang
2026-09-24 8:37 ` Lee Jones
2026-09-24 11:45 ` Rong Zhang [this message]
2026-09-20 19:40 ` [PATCH v7 03/13] leds: class: Remove hardware control trigger when writing brightness Rong Zhang
2026-09-20 19:40 ` [PATCH v7 04/13] leds: trigger: Move led_trigger_group to the right place Rong Zhang
2026-09-20 19:40 ` [PATCH v7 05/13] leds: trigger: Add hw_offloaded() callback and provide trigger_may_offload_to_hw attribute Rong Zhang
2026-09-20 19:40 ` [PATCH v7 06/13] leds: cros_ec: Implement hw_offloaded() trigger callback Rong Zhang
2026-09-20 19:40 ` [PATCH v7 07/13] leds: turris-omnia: Implement hw_offloaded() trigger callback and declare hw_control_trigger Rong Zhang
2026-09-20 19:40 ` [PATCH v7 08/13] leds: trigger: netdev: Implement hw_offloaded() callback Rong Zhang
2026-09-24 8:53 ` Lee Jones
2026-09-24 11:47 ` Rong Zhang
2026-09-20 19:40 ` [PATCH v7 09/13] leds: trigger: Enforce strict checks in led_trigger_is_hw_controlled() Rong Zhang
2026-09-20 19:40 ` [PATCH v7 10/13] leds: trigger: Add led_trigger_notify_hw_control_changed() interface Rong Zhang
2026-09-20 19:40 ` [PATCH v7 11/13] platform/x86: ideapad-laptop: Serialize keyboard backlight tracking Rong Zhang
2026-09-20 19:40 ` [PATCH v7 12/13] platform/x86: ideapad-laptop: Decouple hardware & classdev brightness for keyboard backlight Rong Zhang
2026-09-20 19:40 ` [PATCH v7 13/13] platform/x86: ideapad-laptop: Fully support auto " Rong Zhang
2026-09-24 12:25 ` (subset) [PATCH v7 00/13] leds: Add support for hardware-initiated hardware control trigger transition Lee Jones
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=577cdb9848906b6b2efcfaff2d68f5ef9a769ae9.camel@rong.moe \
--to=i@rong.moe \
--cc=andrew+netdev@lunn.ch \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=corbet@lwn.net \
--cc=derekjohn.clark@gmail.com \
--cc=groeck@chromium.org \
--cc=hansg@kernel.org \
--cc=ikepanhc@gmail.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=kabel@kernel.org \
--cc=kuba@kernel.org \
--cc=lee@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=mpearson-lenovo@squebb.ca \
--cc=netdev@vger.kernel.org \
--cc=pavel@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=vishnuocv@gmail.com \
--cc=vsankar@lenovo.com \
/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
all inboxes | Powered by JetHome®