From: Lee Jones <lee@kernel.org>
To: Rong Zhang <i@rong.moe>
Cc: "Pavel Machek" <pavel@kernel.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>,
"Vishnu Sankar" <vishnuocv@gmail.com>,
vsankar@lenovo.com, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, chrome-platform@lists.linux.dev,
platform-driver-x86@vger.kernel.org
Subject: Re: [RFC PATCH 1/9] leds: Load trigger modules on-demand if used as hw control trigger
Date: Tue, 10 Mar 2026 12:01:16 +0000 [thread overview]
Message-ID: <20260310120116.GI183676@google.com> (raw)
In-Reply-To: <20260227190617.271388-2-i@rong.moe>
On Sat, 28 Feb 2026, Rong Zhang wrote:
> In the following patches, we are about to support hardware initiated
Let's not talk about other commits. Only tell us what's happening here.
> trigger transitions to/from the device's hw control trigger. In case
> the LED hardware switches itself to hw control mode, hw control trigger
> must be loaded before so that the transition can be processed.
>
> Load the trigger module specified by hw_control_trigger, so that
> hardware initiated trigger transitions can be processed when the hw
"hardware"
> control trigger is compiled as a module.
>
> Signed-off-by: Rong Zhang <i@rong.moe>
> ---
> drivers/leds/led-class.c | 1 +
> drivers/leds/led-triggers.c | 33 +++++++++++++++++++++++++++++++++
> drivers/leds/leds.h | 1 +
> 3 files changed, 35 insertions(+)
>
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index d34a194535604..0fa45f22246e3 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -576,6 +576,7 @@ int led_classdev_register_ext(struct device *parent,
>
> #ifdef CONFIG_LEDS_TRIGGERS
> led_trigger_set_default(led_cdev);
> + led_load_hw_control_trigger(led_cdev);
led_trigger_load_hw_control
> #endif
>
> mutex_unlock(&led_cdev->led_access);
> diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
> index b1223218bda11..3066bc91a5f94 100644
> --- a/drivers/leds/led-triggers.c
> +++ b/drivers/leds/led-triggers.c
> @@ -313,6 +313,39 @@ void led_trigger_set_default(struct led_classdev *led_cdev)
> }
> EXPORT_SYMBOL_GPL(led_trigger_set_default);
>
> +static inline bool led_match_hw_control_trigger(struct led_classdev *led_cdev,
> + struct led_trigger *trig)
> +{
> + return (!strcmp(led_cdev->hw_control_trigger, trig->name) &&
> + trigger_relevant(led_cdev, trig));
This is ugly. Break it out and provide some commentary.
> +}
> +
> +void led_load_hw_control_trigger(struct led_classdev *led_cdev)
> +{
> + struct led_trigger *trig;
> + bool found = false;
> +
> + if (!led_cdev->hw_control_trigger)
> + return;
> +
> + /* default_trigger is handled by led_trigger_set_default(). */
Sentences start with uppercase chars.
> + if (led_cdev->default_trigger &&
> + !strcmp(led_cdev->default_trigger, led_cdev->hw_control_trigger))
> + return;
Do you need to check default_trigger?
strcmp() should be able to handle empty strings.
> +
> + down_read(&triggers_list_lock);
> + list_for_each_entry(trig, &trigger_list, next_trig) {
> + found = led_match_hw_control_trigger(led_cdev, trig);
> + if (found)
> + break;
> + }
> + up_read(&triggers_list_lock);
> +
> + if (!found)
> + request_module_nowait("ledtrig:%s", led_cdev->hw_control_trigger);
> +}
> +EXPORT_SYMBOL_GPL(led_load_hw_control_trigger);
> +
> /* LED Trigger Interface */
>
> int led_trigger_register(struct led_trigger *trig)
> diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
> index bee46651e068f..e85afd4d04fd0 100644
> --- a/drivers/leds/leds.h
> +++ b/drivers/leds/leds.h
> @@ -21,6 +21,7 @@ void led_init_core(struct led_classdev *led_cdev);
> void led_stop_software_blink(struct led_classdev *led_cdev);
> void led_set_brightness_nopm(struct led_classdev *led_cdev, unsigned int value);
> void led_set_brightness_nosleep(struct led_classdev *led_cdev, unsigned int value);
> +void led_load_hw_control_trigger(struct led_classdev *led_cdev);
> ssize_t led_trigger_read(struct file *filp, struct kobject *kobj,
> const struct bin_attribute *attr, char *buf,
> loff_t pos, size_t count);
> --
> 2.51.0
>
--
Lee Jones [李琼斯]
next prev parent reply other threads:[~2026-03-10 12:01 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-27 19:05 [RFC PATCH 0/9] leds: Add support for hw initiated hw control trigger transition Rong Zhang
2026-02-27 19:05 ` [RFC PATCH 1/9] leds: Load trigger modules on-demand if used as hw control trigger Rong Zhang
2026-03-10 12:01 ` Lee Jones [this message]
2026-03-11 16:18 ` Rong Zhang
2026-03-10 19:22 ` Andrew Lunn
2026-03-11 18:17 ` Rong Zhang
2026-03-11 18:44 ` Andrew Lunn
2026-03-11 19:39 ` Rong Zhang
2026-03-11 21:29 ` Andrew Lunn
2026-03-12 18:01 ` Rong Zhang
2026-03-12 21:46 ` Mark Pearson
2026-03-13 14:01 ` Rong Zhang
2026-03-14 19:02 ` Mark Pearson
2026-02-27 19:05 ` [RFC PATCH 2/9] leds: Add callback offloaded() to query the state of " Rong Zhang
2026-02-27 19:06 ` [RFC PATCH 3/9] leds: cros_ec: Implement offloaded() callback for trigger Rong Zhang
2026-02-27 19:06 ` [RFC PATCH 4/9] leds: turris-omnia: " Rong Zhang
2026-02-27 19:06 ` [RFC PATCH 5/9] leds: trigger: netdev: Implement offloaded() callback Rong Zhang
2026-02-27 19:06 ` [RFC PATCH 6/9] leds: Add trigger_may_offload attribute Rong Zhang
2026-02-27 19:06 ` [RFC PATCH 7/9] leds: trigger: Add led_trigger_notify_hw_control_changed() interface Rong Zhang
2026-02-27 21:01 ` Randy Dunlap
2026-02-27 19:06 ` [RFC PATCH 8/9] platform/x86: ideapad-laptop: Decouple HW & cdev brightness for kbd backlight Rong Zhang
2026-02-27 19:06 ` [RFC PATCH 9/9] platform/x86: ideapad-laptop: Fully support auto " Rong Zhang
2026-03-04 20:05 ` [RFC PATCH 0/9] leds: Add support for hw initiated hw control trigger transition Mark Pearson
2026-03-05 12:00 ` Vishnu Sankar
2026-03-05 12:37 ` Rong Zhang
2026-03-08 17:44 ` Mark Pearson
2026-03-10 20:03 ` Andrew Lunn
2026-03-10 12:10 ` Lee Jones
2026-03-10 19:04 ` Andrew Lunn
2026-03-11 18:18 ` Rong Zhang
2026-03-10 19:57 ` Andrew Lunn
2026-03-11 19:03 ` Rong Zhang
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=20260310120116.GI183676@google.com \
--to=lee@kernel.org \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=derekjohn.clark@gmail.com \
--cc=groeck@chromium.org \
--cc=hansg@kernel.org \
--cc=i@rong.moe \
--cc=ikepanhc@gmail.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=kabel@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=mpearson-lenovo@squebb.ca \
--cc=pavel@kernel.org \
--cc=platform-driver-x86@vger.kernel.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