From: sashiko-bot@kernel.org
To: "Rong Zhang" <i@rong.moe>
Cc: linux-leds@vger.kernel.org, lee@kernel.org
Subject: Re: [PATCH v4 04/12] leds: cros_ec: Implement offloaded() trigger callback
Date: Sun, 02 Aug 2026 17:31:47 +0000 [thread overview]
Message-ID: <20260802173147.EAE361F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260802-leds-trigger-hw-changed-v4-4-f97e2ca976fe@rong.moe>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Registering a global static `led_trigger` structure in a driver's probe function causes list corruption and lock re-initialization if the driver is probed multiple times.
--
--- Patch [4]: [PATCH v4 04/12] leds: cros_ec: Implement offloaded() trigger callback ---
commit 74008c8c0e283ff69ceee35b25286706470006e0
Author: Rong Zhang <i@rong.moe>
leds: cros_ec: Implement offloaded() trigger callback
"chromeos-auto" is a private hardware control trigger which always stays
in hardware control. Implement offloaded() callback with its return
value to be always true to reflect this.
> diff --git a/drivers/leds/leds-cros_ec.c b/drivers/leds/leds-cros_ec.c
> index 1844d0cd5f528..6db83d0152775 100644
> --- a/drivers/leds/leds-cros_ec.c
> +++ b/drivers/leds/leds-cros_ec.c
[ ... ]
> static struct led_hw_trigger_type cros_ec_led_trigger_type;
>
> static struct led_trigger cros_ec_led_trigger = {
> .name = "chromeos-auto",
> .trigger_type = &cros_ec_led_trigger_type,
> .activate = cros_ec_led_trigger_activate,
> + .offloaded = cros_ec_led_trigger_offloaded,
> };
[Severity: High]
This is a pre-existing issue, but registering a global static led_trigger
structure in a driver's probe function can cause list corruption and lock
re-initialization if the driver is probed multiple times.
When cros_ec_led_probe() calls devm_led_trigger_register() and passes
this global static cros_ec_led_trigger struct, led_trigger_register()
unconditionally re-initializes the led_cdevs list and leddev_list_lock
on the passed pointer before checking if it already exists:
drivers/leds/led-triggers.c:led_trigger_register() {
...
spin_lock_init(&trig->leddev_list_lock);
INIT_LIST_HEAD(&trig->led_cdevs);
...
}
Does this corrupt the state of the active trigger if a subsequent probe
(such as for a second EC or manually via sysfs) calls it again with the
exact same static pointer?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260802-leds-trigger-hw-changed-v4-0-f97e2ca976fe@rong.moe?part=4
next prev parent reply other threads:[~2026-08-02 17:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-01 17:26 [PATCH v4 00/12] leds: Add support for hardware-initiated hardware control trigger transition Rong Zhang
2026-08-01 17:26 ` [PATCH v4 01/12] leds: Move led_trigger_is_hw_controlled() to the right place Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 02/12] leds: class: Remove hardware control trigger when writing brightness Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 03/12] leds: trigger: Add offloaded() callback and provide trigger_may_offload attribute Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 04/12] leds: cros_ec: Implement offloaded() trigger callback Rong Zhang
2026-08-02 17:31 ` sashiko-bot [this message]
2026-08-01 17:26 ` [PATCH v4 05/12] leds: turris-omnia: Implement offloaded() trigger callback and declare hw_control_trigger Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 06/12] leds: trigger: netdev: Implement offloaded() callback Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 07/12] leds: trigger: Enforce strict checks in led_trigger_is_hw_controlled() Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 08/12] leds: trigger: Do not attach trigger to a removing LED Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 09/12] leds: trigger: Add led_trigger_notify_hw_control_changed() interface Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 10/12] platform/x86: ideapad-laptop: Decouple hardware & classdev brightness for keyboard backlight Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 11/12] platform/x86: ideapad-laptop: Serialize keyboard backlight notifications Rong Zhang
2026-08-02 17:31 ` sashiko-bot
2026-08-01 17:26 ` [PATCH v4 12/12] platform/x86: ideapad-laptop: Fully support auto keyboard backlight Rong Zhang
2026-08-02 17:31 ` sashiko-bot
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=20260802173147.EAE361F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=i@rong.moe \
--cc=lee@kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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