* [PATCH net v3 1/2] af_unix: fix listen() succeeding on sockets in the wrong state
From: John Ericson @ 2026-07-18 18:29 UTC (permalink / raw)
To: Kuniyuki Iwashima, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: John Ericson, Simon Horman, Christian Brauner, David Rheinsberg,
Cong Wang, Sergei Zimmerman, netdev, linux-kernel
From: John Ericson <mail@johnericson.me>
Commit fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for
reaped sk->sk_peer_pid") inserted a prepare_peercred() call between err
= -EINVAL and the socket-state check in unix_listen(). Since
prepare_peercred() leaves err at 0 on success, listen() on an AF_UNIX
socket that is not in TCP_CLOSE or TCP_LISTEN state (e.g. one that is
already connected) now silently returns success without doing anything,
instead of failing with EINVAL as it did before.
Fixes: fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid")
Assisted-by: Claude:claude-fable-5
Signed-off-by: John Ericson <mail@johnericson.me>
---
net/unix/af_unix.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index f7a9d55eee8a..10ed9421e43a 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -823,6 +823,7 @@ static int unix_listen(struct socket *sock, int backlog)
if (err)
goto out;
unix_state_lock(sk);
+ err = -EINVAL;
if (sk->sk_state != TCP_CLOSE && sk->sk_state != TCP_LISTEN)
goto out_unlock;
if (backlog > sk->sk_max_ack_backlog)
--
2.54.0
^ permalink raw reply related
* [PATCH RFC v3 11/11] platform/x86: ideapad-laptop: Fully support auto keyboard backlight
From: Rong Zhang @ 2026-07-18 17:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Thomas Weißschuh, Benson Leung, Guenter Roeck,
Marek Behún, Mark Pearson, Derek J. Clark, Hans de Goede,
Ilpo Järvinen, Ike Panhc
Cc: Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86, Rong Zhang
In-Reply-To: <20260719-leds-trigger-hw-changed-v3-0-5fb55722e36e@rong.moe>
Currently, the auto brightness mode of keyboard backlight maps to
brightness=0 in LED classdev. The only method to switch to such a mode
is by pressing the manufacturer-defined shortcut (Fn+Space). However, 0
is a multiplexed brightness value; writing 0 simply results in the
backlight being turned off.
With brightness processing code decoupled from LED classdev, we can now
fully support the auto brightness mode. In this mode, the keyboard
backlight is controlled by the EC according to the ambient light sensor
(ALS).
To utilize this, a private hardware control trigger "ideapad-auto" is
added, with the event handling procedure calling the
led_trigger_notify_hw_control_changed() interface to activate/deactivate
the private trigger according to the current LED trigger state.
Meanwhile, block brightness changes on exit to prevent the side effect
of LED device unregistration when the private trigger is active from
resetting the brightness to zero, so that we can retain the state of
auto mode among boots.
Signed-off-by: Rong Zhang <i@rong.moe>
---
Changes in v3:
- Address concerns from Sashiko
- Fix a race condition in ideapad_kbd_bl_led_cdev_brightness_set()
- Fix trigger re-registration of ideapad_kbd_bl_auto_trigger
- https://sashiko.dev/#/patchset/20260618-leds-trigger-hw-changed-v2-0-c28c44053cf3%40rong.moe
- Make registration failures of ideapad_kbd_bl_auto_trigger non-fatal
---
drivers/platform/x86/lenovo/ideapad-laptop.c | 112 ++++++++++++++++++++++++---
1 file changed, 103 insertions(+), 9 deletions(-)
diff --git a/drivers/platform/x86/lenovo/ideapad-laptop.c b/drivers/platform/x86/lenovo/ideapad-laptop.c
index 66e16abda5e3..253d2962b927 100644
--- a/drivers/platform/x86/lenovo/ideapad-laptop.c
+++ b/drivers/platform/x86/lenovo/ideapad-laptop.c
@@ -1714,9 +1714,58 @@ static int ideapad_kbd_bl_led_cdev_brightness_set(struct led_classdev *led_cdev,
{
struct ideapad_private *priv = container_of(led_cdev, struct ideapad_private, kbd_bl.led);
+ /*
+ * When deinitializing: It must be the side effect of led_cdev
+ * unregistration when our private trigger is active. We've set
+ * LED_RETAIN_AT_SHUTDOWN to retain led_cdev brightness level.
+ * To do the same for auto mode, gate changes and return early.
+ */
+ if (unlikely(!priv->kbd_bl.initialized))
+ return 0;
+
return ideapad_kbd_bl_brightness_set(priv, brightness);
}
+static bool ideapad_kbd_bl_auto_trigger_offloaded(struct led_classdev *led_cdev)
+{
+ struct ideapad_private *priv = container_of(led_cdev, struct ideapad_private, kbd_bl.led);
+
+ return atomic_read(&priv->kbd_bl.last_hw_brightness) == KBD_BL_AUTO_MODE_HW_BRIGHTNESS;
+}
+
+static int ideapad_kbd_bl_auto_trigger_activate(struct led_classdev *led_cdev)
+{
+ struct ideapad_private *priv = container_of(led_cdev, struct ideapad_private, kbd_bl.led);
+
+ return ideapad_kbd_bl_hw_brightness_set(priv, KBD_BL_AUTO_MODE_HW_BRIGHTNESS);
+}
+
+static struct led_hw_trigger_type ideapad_kbd_bl_auto_trigger_type;
+
+static struct led_trigger ideapad_kbd_bl_auto_trigger = {
+ .name = "ideapad-auto",
+ .trigger_type = &ideapad_kbd_bl_auto_trigger_type,
+ .activate = ideapad_kbd_bl_auto_trigger_activate,
+ .offloaded = ideapad_kbd_bl_auto_trigger_offloaded,
+};
+
+static bool ideapad_kbd_bl_auto_trigger_registered;
+
+static void ideapad_kbd_bl_notify_hw_control(struct ideapad_private *priv,
+ int hw_brightness, int last_hw_brightness)
+{
+ bool hw_control, last_hw_control;
+
+ if (priv->kbd_bl.type != KBD_BL_TRISTATE_AUTO)
+ return;
+
+ hw_control = hw_brightness == KBD_BL_AUTO_MODE_HW_BRIGHTNESS;
+ last_hw_control = last_hw_brightness == KBD_BL_AUTO_MODE_HW_BRIGHTNESS;
+
+ if (hw_control != last_hw_control)
+ led_trigger_notify_hw_control_changed(&priv->kbd_bl.led, hw_control);
+}
+
static void ideapad_kbd_bl_notify(struct ideapad_private *priv)
{
int hw_brightness, brightness, last_hw_brightness;
@@ -1738,6 +1787,8 @@ static void ideapad_kbd_bl_notify(struct ideapad_private *priv)
if (hw_brightness == last_hw_brightness)
return;
+ ideapad_kbd_bl_notify_hw_control(priv, hw_brightness, last_hw_brightness);
+
led_classdev_notify_brightness_hw_changed(&priv->kbd_bl.led, brightness);
}
@@ -1768,6 +1819,24 @@ static int ideapad_kbd_bl_init(struct ideapad_private *priv)
switch (priv->kbd_bl.type) {
case KBD_BL_TRISTATE_AUTO:
+ priv->kbd_bl.led.max_brightness = 2;
+
+ if (!ideapad_kbd_bl_auto_trigger_registered) {
+ dev_warn(&priv->platform_device->dev,
+ "Could not provide LED trigger %s for keyboard backlight\n",
+ ideapad_kbd_bl_auto_trigger.name);
+ break;
+ }
+
+ priv->kbd_bl.led.flags |= LED_TRIG_HW_CHANGED;
+ priv->kbd_bl.led.hw_control_trigger = ideapad_kbd_bl_auto_trigger.name;
+ priv->kbd_bl.led.trigger_type = &ideapad_kbd_bl_auto_trigger_type;
+
+ /* Hardware remembers the last brightness level, including auto mode. */
+ if (hw_brightness == KBD_BL_AUTO_MODE_HW_BRIGHTNESS)
+ priv->kbd_bl.led.default_trigger = ideapad_kbd_bl_auto_trigger.name;
+
+ break;
case KBD_BL_TRISTATE:
priv->kbd_bl.led.max_brightness = 2;
break;
@@ -1779,13 +1848,22 @@ static int ideapad_kbd_bl_init(struct ideapad_private *priv)
unreachable();
}
- err = led_classdev_register(&priv->platform_device->dev, &priv->kbd_bl.led);
- if (err)
- return err;
+ /* Queue notifications, as kbd_bl.initialized is about to be set. */
+ guard(mutex)(&priv->kbd_bl.notif_mutex);
+ /*
+ * Setting kbd_bl.initialized after led_classdev_register() could lead
+ * to race conditions in ideapad_kbd_bl_led_cdev_brightness_set() where
+ * kbd_bl.initialized is checked, so set it now. It can be reverted back
+ * if the LED classdev failed to register.
+ */
priv->kbd_bl.initialized = true;
- return 0;
+ err = led_classdev_register(&priv->platform_device->dev, &priv->kbd_bl.led);
+ if (err)
+ priv->kbd_bl.initialized = false;
+
+ return err;
}
static void ideapad_kbd_bl_exit(struct ideapad_private *priv)
@@ -2612,17 +2690,30 @@ static int __init ideapad_laptop_init(void)
{
int err;
+ err = led_trigger_register(&ideapad_kbd_bl_auto_trigger);
+ if (err) {
+ pr_warn("Failed to register LED trigger %s: %d\n",
+ ideapad_kbd_bl_auto_trigger.name, err);
+ } else {
+ ideapad_kbd_bl_auto_trigger_registered = true;
+ }
+
err = ideapad_wmi_driver_register();
if (err)
- return err;
+ goto err_ledtrig;
err = platform_driver_register(&ideapad_acpi_driver);
- if (err) {
- ideapad_wmi_driver_unregister();
- return err;
- }
+ if (err)
+ goto err_wmi;
return 0;
+
+err_wmi:
+ ideapad_wmi_driver_unregister();
+err_ledtrig:
+ if (ideapad_kbd_bl_auto_trigger_registered)
+ led_trigger_unregister(&ideapad_kbd_bl_auto_trigger);
+ return err;
}
module_init(ideapad_laptop_init)
@@ -2630,6 +2721,9 @@ static void __exit ideapad_laptop_exit(void)
{
ideapad_wmi_driver_unregister();
platform_driver_unregister(&ideapad_acpi_driver);
+
+ if (ideapad_kbd_bl_auto_trigger_registered)
+ led_trigger_unregister(&ideapad_kbd_bl_auto_trigger);
}
module_exit(ideapad_laptop_exit)
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v3 10/11] platform/x86: ideapad-laptop: Serialize keyboard backlight notifications
From: Rong Zhang @ 2026-07-18 17:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Thomas Weißschuh, Benson Leung, Guenter Roeck,
Marek Behún, Mark Pearson, Derek J. Clark, Hans de Goede,
Ilpo Järvinen, Ike Panhc
Cc: Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86, Rong Zhang
In-Reply-To: <20260719-leds-trigger-hw-changed-v3-0-5fb55722e36e@rong.moe>
ACPI notifications are delivered in dedicated work contexts and may
arrive simultaneously. In the following change, much work will be done
while handling the notification, which could lead to potential race
conditions.
Introduce a new mutex to serialize keyboard backlight notifications to
prevent potential race conditions.
Signed-off-by: Rong Zhang <i@rong.moe>
---
drivers/platform/x86/lenovo/ideapad-laptop.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/platform/x86/lenovo/ideapad-laptop.c b/drivers/platform/x86/lenovo/ideapad-laptop.c
index 5aa2fedb8472..66e16abda5e3 100644
--- a/drivers/platform/x86/lenovo/ideapad-laptop.c
+++ b/drivers/platform/x86/lenovo/ideapad-laptop.c
@@ -26,7 +26,9 @@
#include <linux/jiffies.h>
#include <linux/kernel.h>
#include <linux/leds.h>
+#include <linux/lockdep.h>
#include <linux/module.h>
+#include <linux/mutex.h>
#include <linux/platform_device.h>
#include <linux/platform_profile.h>
#include <linux/power_supply.h>
@@ -228,6 +230,8 @@ struct ideapad_private {
int type;
struct led_classdev led;
atomic_t last_hw_brightness;
+
+ struct mutex notif_mutex; /* protects notifications */
} kbd_bl;
struct {
bool initialized;
@@ -1720,6 +1724,8 @@ static void ideapad_kbd_bl_notify(struct ideapad_private *priv)
if (!priv->kbd_bl.initialized)
return;
+ guard(mutex)(&priv->kbd_bl.notif_mutex);
+
hw_brightness = ideapad_kbd_bl_hw_brightness_get(priv);
if (hw_brightness < 0)
return;
@@ -1745,6 +1751,10 @@ static int ideapad_kbd_bl_init(struct ideapad_private *priv)
if (WARN_ON(priv->kbd_bl.initialized))
return -EEXIST;
+ err = devm_mutex_init(&priv->platform_device->dev, &priv->kbd_bl.notif_mutex);
+ if (err)
+ return err;
+
hw_brightness = ideapad_kbd_bl_hw_brightness_get(priv);
if (hw_brightness < 0)
return hw_brightness;
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v3 09/11] platform/x86: ideapad-laptop: Decouple hardware & classdev brightness for keyboard backlight
From: Rong Zhang @ 2026-07-18 17:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Thomas Weißschuh, Benson Leung, Guenter Roeck,
Marek Behún, Mark Pearson, Derek J. Clark, Hans de Goede,
Ilpo Järvinen, Ike Panhc
Cc: Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86, Rong Zhang
In-Reply-To: <20260719-leds-trigger-hw-changed-v3-0-5fb55722e36e@rong.moe>
Some recent models come with an ambient light sensor (ALS). On these
models, their EC will automatically set the keyboard backlight to an
appropriate brightness when the effective "hardware brightness" is 3.
"Hardware brightness" can't be perfectly mapped to an LED classdev
brightness, but the EC does use this predefined brightness value to
represent auto mode.
Currently, the code processing keyboard backlight is coupled with LED
classdev, making it hard to expose the auto brightness (ALS) mode to the
userspace.
As the first step toward the goal, decouple hardware brightness from LED
classdev brightness, and update comments about corresponding backlight
modes.
Since upcoming changes will heavily rely on kbd_bl.last_hw_brightness,
also convert it into an atomic_t to prevent potential race conditions.
To minimalize the diff set in upcoming changes, a trivial refactor
also converts the initialization path into another equivalent form.
Signed-off-by: Rong Zhang <i@rong.moe>
---
drivers/platform/x86/lenovo/Kconfig | 1 +
drivers/platform/x86/lenovo/ideapad-laptop.c | 144 ++++++++++++++++++---------
2 files changed, 100 insertions(+), 45 deletions(-)
diff --git a/drivers/platform/x86/lenovo/Kconfig b/drivers/platform/x86/lenovo/Kconfig
index 4443f40ef8aa..e92b1e900795 100644
--- a/drivers/platform/x86/lenovo/Kconfig
+++ b/drivers/platform/x86/lenovo/Kconfig
@@ -16,6 +16,7 @@ config IDEAPAD_LAPTOP
select INPUT_SPARSEKMAP
select NEW_LEDS
select LEDS_CLASS
+ select LEDS_TRIGGERS
help
This is a driver for Lenovo IdeaPad netbooks contains drivers for
rfkill switch, hotkey, fan control and backlight control.
diff --git a/drivers/platform/x86/lenovo/ideapad-laptop.c b/drivers/platform/x86/lenovo/ideapad-laptop.c
index 4fbc904f1fc3..5aa2fedb8472 100644
--- a/drivers/platform/x86/lenovo/ideapad-laptop.c
+++ b/drivers/platform/x86/lenovo/ideapad-laptop.c
@@ -9,6 +9,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/acpi.h>
+#include <linux/atomic.h>
#include <linux/backlight.h>
#include <linux/bitfield.h>
#include <linux/bitops.h>
@@ -134,10 +135,31 @@ enum {
};
/*
- * These correspond to the number of supported states - 1
- * Future keyboard types may need a new system, if there's a collision
- * KBD_BL_TRISTATE_AUTO has no way to report or set the auto state
- * so it effectively has 3 states, but needs to handle 4
+ * The enumeration has two purposes:
+ * - as an internal identifier for all known types of keyboard backlight
+ * - as a mandatory parameter of the KBLC command
+ *
+ * For each type, the hardware brightness values are defined as follows:
+ * +--------------------------+----------+-----+------+------+
+ * | Hardware brightness | 0 | 1 | 2 | 3 |
+ * | Type | | | | |
+ * +--------------------------+----------+-----+------+------+
+ * | KBD_BL_STANDARD | off | on | N/A | N/A |
+ * +--------------------------+----------+-----+------+------+
+ * | KBD_BL_TRISTATE | off | low | high | N/A |
+ * +--------------------------+----------+-----+------+------+
+ * | KBD_BL_TRISTATE_AUTO | off | low | high | auto |
+ * +--------------------------+----------+-----+------+------+
+ *
+ * We map LED classdev brightness for KBD_BL_TRISTATE_AUTO as follows:
+ * +--------------------------+----------+-----+------+
+ * | LED classdev brightness | 0 | 1 | 2 |
+ * | Operation | | | |
+ * +--------------------------+----------+-----+------+
+ * | Read | off/auto | low | high |
+ * +--------------------------+----------+-----+------+
+ * | Write | off | low | high |
+ * +--------------------------+----------+-----+------+
*/
enum {
KBD_BL_STANDARD = 1,
@@ -145,6 +167,8 @@ enum {
KBD_BL_TRISTATE_AUTO = 3,
};
+#define KBD_BL_AUTO_MODE_HW_BRIGHTNESS 3
+
#define KBD_BL_QUERY_TYPE 0x1
#define KBD_BL_TRISTATE_TYPE 0x5
#define KBD_BL_TRISTATE_AUTO_TYPE 0x7
@@ -203,7 +227,7 @@ struct ideapad_private {
bool initialized;
int type;
struct led_classdev led;
- unsigned int last_brightness;
+ atomic_t last_hw_brightness;
} kbd_bl;
struct {
bool initialized;
@@ -1592,7 +1616,24 @@ static int ideapad_kbd_bl_check_tristate(int type)
return (type == KBD_BL_TRISTATE) || (type == KBD_BL_TRISTATE_AUTO);
}
-static int ideapad_kbd_bl_brightness_get(struct ideapad_private *priv)
+static int ideapad_kbd_bl_brightness_parse(struct ideapad_private *priv, int hw_brightness)
+{
+ /* Off, low or high */
+ if (hw_brightness <= priv->kbd_bl.led.max_brightness)
+ return hw_brightness;
+
+ /* Auto (controlled by EC according to ALS), report as off */
+ if (priv->kbd_bl.type == KBD_BL_TRISTATE_AUTO &&
+ hw_brightness == KBD_BL_AUTO_MODE_HW_BRIGHTNESS)
+ return 0;
+
+ /* Unknown value */
+ dev_warn(&priv->platform_device->dev,
+ "Unknown keyboard backlight value: %d", hw_brightness);
+ return -EINVAL;
+}
+
+static int ideapad_kbd_bl_hw_brightness_get(struct ideapad_private *priv)
{
unsigned long value;
int err;
@@ -1606,21 +1647,7 @@ static int ideapad_kbd_bl_brightness_get(struct ideapad_private *priv)
if (err)
return err;
- /* Convert returned value to brightness level */
- value = FIELD_GET(KBD_BL_GET_BRIGHTNESS, value);
-
- /* Off, low or high */
- if (value <= priv->kbd_bl.led.max_brightness)
- return value;
-
- /* Auto, report as off */
- if (value == priv->kbd_bl.led.max_brightness + 1)
- return 0;
-
- /* Unknown value */
- dev_warn(&priv->platform_device->dev,
- "Unknown keyboard backlight value: %lu", value);
- return -EINVAL;
+ return FIELD_GET(KBD_BL_GET_BRIGHTNESS, value);
}
err = eval_hals(priv->adev->handle, &value);
@@ -1630,6 +1657,16 @@ static int ideapad_kbd_bl_brightness_get(struct ideapad_private *priv)
return !!test_bit(HALS_KBD_BL_STATE_BIT, &value);
}
+static int ideapad_kbd_bl_brightness_get(struct ideapad_private *priv)
+{
+ int hw_brightness = ideapad_kbd_bl_hw_brightness_get(priv);
+
+ if (hw_brightness < 0)
+ return hw_brightness;
+
+ return ideapad_kbd_bl_brightness_parse(priv, hw_brightness);
+}
+
static enum led_brightness ideapad_kbd_bl_led_cdev_brightness_get(struct led_classdev *led_cdev)
{
struct ideapad_private *priv = container_of(led_cdev, struct ideapad_private, kbd_bl.led);
@@ -1637,32 +1674,37 @@ static enum led_brightness ideapad_kbd_bl_led_cdev_brightness_get(struct led_cla
return ideapad_kbd_bl_brightness_get(priv);
}
-static int ideapad_kbd_bl_brightness_set(struct ideapad_private *priv, unsigned int brightness)
+static int ideapad_kbd_bl_hw_brightness_set(struct ideapad_private *priv, int hw_brightness)
{
- int err;
unsigned long value;
int type = priv->kbd_bl.type;
+ int err;
if (ideapad_kbd_bl_check_tristate(type)) {
- if (brightness > priv->kbd_bl.led.max_brightness)
- return -EINVAL;
-
- value = FIELD_PREP(KBD_BL_SET_BRIGHTNESS, brightness) |
+ value = FIELD_PREP(KBD_BL_SET_BRIGHTNESS, hw_brightness) |
FIELD_PREP(KBD_BL_COMMAND_TYPE, type) |
KBD_BL_COMMAND_SET;
err = exec_kblc(priv->adev->handle, value);
} else {
- err = exec_sals(priv->adev->handle, brightness ? SALS_KBD_BL_ON : SALS_KBD_BL_OFF);
+ value = hw_brightness ? SALS_KBD_BL_ON : SALS_KBD_BL_OFF;
+ err = exec_sals(priv->adev->handle, value);
}
-
if (err)
return err;
- priv->kbd_bl.last_brightness = brightness;
+ atomic_set(&priv->kbd_bl.last_hw_brightness, hw_brightness);
return 0;
}
+static int ideapad_kbd_bl_brightness_set(struct ideapad_private *priv, int brightness)
+{
+ if (brightness > priv->kbd_bl.led.max_brightness)
+ return -EINVAL;
+
+ return ideapad_kbd_bl_hw_brightness_set(priv, brightness);
+}
+
static int ideapad_kbd_bl_led_cdev_brightness_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
@@ -1673,26 +1715,29 @@ static int ideapad_kbd_bl_led_cdev_brightness_set(struct led_classdev *led_cdev,
static void ideapad_kbd_bl_notify(struct ideapad_private *priv)
{
- int brightness;
+ int hw_brightness, brightness, last_hw_brightness;
if (!priv->kbd_bl.initialized)
return;
- brightness = ideapad_kbd_bl_brightness_get(priv);
- if (brightness < 0)
+ hw_brightness = ideapad_kbd_bl_hw_brightness_get(priv);
+ if (hw_brightness < 0)
return;
- if (brightness == priv->kbd_bl.last_brightness)
- return;
+ brightness = ideapad_kbd_bl_brightness_parse(priv, hw_brightness);
+ if (brightness < 0)
+ return; /* Reject insane values early. */
- priv->kbd_bl.last_brightness = brightness;
+ last_hw_brightness = atomic_xchg(&priv->kbd_bl.last_hw_brightness, hw_brightness);
+ if (hw_brightness == last_hw_brightness)
+ return;
led_classdev_notify_brightness_hw_changed(&priv->kbd_bl.led, brightness);
}
static int ideapad_kbd_bl_init(struct ideapad_private *priv)
{
- int brightness, err;
+ int hw_brightness, err;
if (!priv->features.kbd_bl)
return -ENODEV;
@@ -1700,21 +1745,30 @@ static int ideapad_kbd_bl_init(struct ideapad_private *priv)
if (WARN_ON(priv->kbd_bl.initialized))
return -EEXIST;
- if (ideapad_kbd_bl_check_tristate(priv->kbd_bl.type))
- priv->kbd_bl.led.max_brightness = 2;
- else
- priv->kbd_bl.led.max_brightness = 1;
+ hw_brightness = ideapad_kbd_bl_hw_brightness_get(priv);
+ if (hw_brightness < 0)
+ return hw_brightness;
- brightness = ideapad_kbd_bl_brightness_get(priv);
- if (brightness < 0)
- return brightness;
+ atomic_set(&priv->kbd_bl.last_hw_brightness, hw_brightness);
- priv->kbd_bl.last_brightness = brightness;
priv->kbd_bl.led.name = "platform::" LED_FUNCTION_KBD_BACKLIGHT;
priv->kbd_bl.led.brightness_get = ideapad_kbd_bl_led_cdev_brightness_get;
priv->kbd_bl.led.brightness_set_blocking = ideapad_kbd_bl_led_cdev_brightness_set;
priv->kbd_bl.led.flags = LED_BRIGHT_HW_CHANGED | LED_RETAIN_AT_SHUTDOWN;
+ switch (priv->kbd_bl.type) {
+ case KBD_BL_TRISTATE_AUTO:
+ case KBD_BL_TRISTATE:
+ priv->kbd_bl.led.max_brightness = 2;
+ break;
+ case KBD_BL_STANDARD:
+ priv->kbd_bl.led.max_brightness = 1;
+ break;
+ default:
+ /* This has already been validated by ideapad_check_features(). */
+ unreachable();
+ }
+
err = led_classdev_register(&priv->platform_device->dev, &priv->kbd_bl.led);
if (err)
return err;
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v3 08/11] leds: trigger: Add led_trigger_notify_hw_control_changed() interface
From: Rong Zhang @ 2026-07-18 17:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Thomas Weißschuh, Benson Leung, Guenter Roeck,
Marek Behún, Mark Pearson, Derek J. Clark, Hans de Goede,
Ilpo Järvinen, Ike Panhc
Cc: Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86, Rong Zhang
In-Reply-To: <20260719-leds-trigger-hw-changed-v3-0-5fb55722e36e@rong.moe>
Some hardware can autonomously activate/deactivate hardware control.
After that, the LED hardware notifies the LED driver. Currently, there
is no mechanism for LED drivers to notify the LED core about such events
and initiate a trigger transition to reflect the hardware state.
Add a new interface called led_trigger_notify_hw_control_changed(), so
that LED drivers can call it to notify the LED core about the
transition.
The interface only allows two transitions:
1. "none" => private trigger
2. private trigger => "none"
If the current trigger is neither the private trigger nor "none", no
transition will be made. This protects the currently selected software
trigger.
Note that LED_OFF won't be emitted during the #2 transition, as some
hardware may have selected a new brightness level during its hardware
state transition (e.g., laptop keyboards with a shortcut cycling through
different backlight brightnesses and auto mode).
The interface is designed as a void function as any failure should be
non-fatal and the result of transition should not have any impact on the
LED drivers' event handling procedures.
To use the interface, LEDS_TRIGGERS_HW_CHANGED must be enabled in
Kconfig, and the LED driver must set the LED_TRIG_HW_CHANGED flag for
the classdev.
Signed-off-by: Rong Zhang <i@rong.moe>
---
Changes in v3:
- Adopt guard() (Thanks Thomas Weißschuh)
- Reword documentations
---
Documentation/leds/leds-class.rst | 52 +++++++++++++++++++++++++
drivers/leds/led-triggers.c | 82 ++++++++++++++++++++++++++++++++++++++-
drivers/leds/trigger/Kconfig | 9 +++++
include/linux/leds.h | 8 ++++
4 files changed, 149 insertions(+), 2 deletions(-)
diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst
index 2d41a6db602c..adbc57b9f49c 100644
--- a/Documentation/leds/leds-class.rst
+++ b/Documentation/leds/leds-class.rst
@@ -334,6 +334,58 @@ not necessary for them to coordinate via `hw_control_*` callbacks.
When the LED is in hw control, no software blink is possible and doing so
will effectively disable hw control.
+Hardware-initiated trigger transition
+=====================================
+
+Some hardware can autonomously activate/deactivate hardware control. After that,
+the LED hardware notifies the LED driver.
+
+If the driver can detect such transitions and thus wants to notify the LED core
+to update the current trigger then the `LED_TRIG_HW_CHANGED` flag must be set in
+flags before registering. To update the current trigger accordingly, call
+`led_trigger_notify_hw_control_changed` on the LED classdev.
+
+This capability is restricted to the LED device's private trigger. The private
+trigger must have been properly registered (see above) and named after
+`hw_control_trigger`.
+
+Only two transitions are defined:
+
+- "none" => private trigger:
+ This happens when the hardware autonomously activates hardware control
+ and when "none" (i.e., no trigger) is currently active. If the private
+ trigger is already active when the method is called, this is essentially
+ a no-op.
+
+ The activation sequence for the private trigger will be executed as
+ normal.
+
+ The LED driver and its private trigger must be able to handle the
+ activation sequence even if the hardware is currently in hardware
+ control.
+
+ If error occurs in the activation sequence, the LED Trigger core reverts
+ the effective trigger to "none".
+
+- private trigger => "none"
+ This happens when the hardware autonomously deactivates hardware control
+ and when the private trigger is currently active. If "none" (i.e., no
+ trigger) is active when the method is called, this is essentially a
+ no-op.
+
+ The deactivation sequence for the private trigger will be executed as
+ normal, except that the current LED brightness is retained. The reason
+ for keeping the brightness unchanged is that some hardware may choose a
+ specific brightness instead of simply turning off the LED after
+ autonomously deactivating hardware control.
+
+ The LED driver and its private trigger must be able to handle the
+ deactivation sequence even if the hardware is not currently in hardware
+ control.
+
+If the current trigger is neither the private trigger nor "none", no transition
+will be made.
+
Known Issues
============
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 726fa7bf88cf..6ae28cbd1c77 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -7,6 +7,7 @@
* Author: Richard Purdie <rpurdie@openedhand.com>
*/
+#include <linux/bug.h>
#include <linux/cleanup.h>
#include <linux/export.h>
#include <linux/kernel.h>
@@ -192,7 +193,8 @@ ssize_t led_trigger_read(struct file *filp, struct kobject *kobj,
EXPORT_SYMBOL_GPL(led_trigger_read);
/* Caller must ensure led_cdev->trigger_lock held */
-int led_trigger_set(struct led_classdev *led_cdev, struct led_trigger *trig)
+static int __led_trigger_set(struct led_classdev *led_cdev, struct led_trigger *trig,
+ bool hw_triggered)
{
char *event = NULL;
char *envp[2];
@@ -223,7 +225,21 @@ int led_trigger_set(struct led_classdev *led_cdev, struct led_trigger *trig)
led_cdev->trigger_data = NULL;
led_cdev->activated = false;
led_cdev->flags &= ~LED_INIT_DEFAULT_TRIGGER;
- led_set_brightness(led_cdev, LED_OFF);
+
+ /*
+ * Hardware may have selected a new brightness level during its
+ * hardware control transition, so only reset brightness if we
+ * are switching to another trigger or if the switching is not
+ * hardware triggered.
+ *
+ * Note that this does not apply to the error path, as running
+ * into the error path implies a none => private trigger
+ * transition. This hints that the LED driver and its private
+ * trigger must have some fundamental bugs, so don't bother
+ * leaving the LED in an undefined state.
+ */
+ if (trig || !hw_triggered)
+ led_set_brightness(led_cdev, LED_OFF);
}
if (trig) {
spin_lock(&trig->leddev_list_lock);
@@ -287,6 +303,11 @@ int led_trigger_set(struct led_classdev *led_cdev, struct led_trigger *trig)
return ret;
}
+
+int led_trigger_set(struct led_classdev *led_cdev, struct led_trigger *trig)
+{
+ return __led_trigger_set(led_cdev, trig, false);
+}
EXPORT_SYMBOL_GPL(led_trigger_set);
void led_trigger_remove(struct led_classdev *led_cdev)
@@ -467,6 +488,63 @@ int devm_led_trigger_register(struct device *dev,
}
EXPORT_SYMBOL_GPL(devm_led_trigger_register);
+#ifdef CONFIG_LEDS_TRIGGERS_HW_CHANGED
+static void led_trigger_do_hw_control_transition(struct led_classdev *led_cdev, bool activate,
+ struct led_trigger *hc_trig)
+{
+ int err = 0;
+
+ if (!led_cdev->trigger) {
+ /* "none" => private trigger. */
+ if (activate)
+ err = __led_trigger_set(led_cdev, hc_trig, true);
+ } else if (led_cdev->trigger == hc_trig) {
+ /* private trigger => "none". */
+ if (!activate)
+ err = __led_trigger_set(led_cdev, NULL, true);
+ } else {
+ /* Other trigger is active. */
+ dev_dbg(led_cdev->dev,
+ "Ignoring hw control transition (%s %s) while %s is active",
+ activate ? "activate" : "deactivate", hc_trig->name,
+ led_cdev->trigger->name);
+
+ return;
+ }
+
+ if (err)
+ dev_warn(led_cdev->dev, "Failed to %s %s in hw control transition: %d",
+ activate ? "activate" : "deactivate", hc_trig->name, err);
+}
+
+void led_trigger_notify_hw_control_changed(struct led_classdev *led_cdev, bool activate)
+{
+ struct led_trigger *trig;
+
+ /* Restricted to private triggers. */
+ if (WARN_ON(!(led_cdev->flags & LED_TRIG_HW_CHANGED) ||
+ !led_cdev->hw_control_trigger || !led_cdev->trigger_type))
+ return;
+
+ scoped_guard(rwsem_read, &triggers_list_lock) {
+ list_for_each_entry(trig, &trigger_list, next_trig) {
+ if (trig->trigger_type == led_cdev->trigger_type &&
+ !strcmp(trig->name, led_cdev->hw_control_trigger)) {
+ guard(rwsem_write)(&led_cdev->trigger_lock);
+
+ led_trigger_do_hw_control_transition(led_cdev, activate, trig);
+ return;
+ }
+ }
+ }
+
+ dev_err(led_cdev->dev,
+ "%s() is called, but the private trigger (%s) is not properly registered\n",
+ __func__, led_cdev->hw_control_trigger);
+}
+EXPORT_SYMBOL_GPL(led_trigger_notify_hw_control_changed);
+#endif /* CONFIG_LEDS_TRIGGERS_HW_CHANGED */
+
/* Simple LED Trigger Interface */
void led_trigger_event(struct led_trigger *trig,
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index c11282a74b5a..798122154049 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -9,6 +9,15 @@ menuconfig LEDS_TRIGGERS
if LEDS_TRIGGERS
+config LEDS_TRIGGERS_HW_CHANGED
+ bool "LED hardware-initiated trigger transition support"
+ help
+ This option enables support for hardware initiated hardware control
+ transitions, where the LED hardware autonomously switches between
+ "none" (i.e., no trigger) and its private trigger.
+
+ See Documentation/leds/leds-class.rst for details.
+
config LEDS_TRIGGER_TIMER
tristate "LED Timer Trigger"
help
diff --git a/include/linux/leds.h b/include/linux/leds.h
index cc664da33e94..167598962b73 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -109,6 +109,7 @@ struct led_classdev {
#define LED_INIT_DEFAULT_TRIGGER BIT(23)
#define LED_REJECT_NAME_CONFLICT BIT(24)
#define LED_MULTI_COLOR BIT(25)
+#define LED_TRIG_HW_CHANGED BIT(26)
/* set_brightness_work / blink_timer flags, atomic, private. */
unsigned long work_flags;
@@ -609,6 +610,13 @@ led_trigger_get_brightness(const struct led_trigger *trigger)
#endif /* CONFIG_LEDS_TRIGGERS */
+#ifdef CONFIG_LEDS_TRIGGERS_HW_CHANGED
+void led_trigger_notify_hw_control_changed(struct led_classdev *led_cdev, bool activate);
+#else
+static inline void led_trigger_notify_hw_control_changed(struct led_classdev *led_cdev,
+ bool activate) {}
+#endif
+
/* Trigger specific enum */
enum led_trigger_netdev_modes {
TRIGGER_NETDEV_LINK = 0,
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v3 07/11] leds: trigger: Enforce strict checks in led_trigger_is_hw_controlled()
From: Rong Zhang @ 2026-07-18 17:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Thomas Weißschuh, Benson Leung, Guenter Roeck,
Marek Behún, Mark Pearson, Derek J. Clark, Hans de Goede,
Ilpo Järvinen, Ike Panhc
Cc: Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86, Rong Zhang
In-Reply-To: <20260719-leds-trigger-hw-changed-v3-0-5fb55722e36e@rong.moe>
With all existing triggers adopting the new interface, strict checks
could be enforced to make the semantics of hardware control triggers
clearer.
In detail, a hardware control trigger should:
- Implement offloaded() callback to indicate hardware control
- Associate with the LED classdev's hw_control_trigger string
Signed-off-by: Rong Zhang <i@rong.moe>
---
Changes in v3:
- New patch in the series, splitted from PATCH 3 (thanks Thomas
Weißschuh)
---
drivers/leds/led-triggers.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index c3c41ef40f01..726fa7bf88cf 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -42,9 +42,16 @@ static bool __led_trigger_is_hw_controlled(struct led_classdev *led_cdev)
if (!led_cdev->trigger)
return false;
+ if (!led_cdev->hw_control_trigger ||
+ strcmp(led_cdev->hw_control_trigger, led_cdev->trigger->name))
+ return false;
+
if (led_cdev->trigger->offloaded)
return led_cdev->trigger->offloaded(led_cdev);
+ dev_warn_once(led_cdev->dev, "hw control trigger %s doesn't implement offloaded()\n",
+ led_cdev->trigger->name);
+
return led_cdev->trigger->trigger_type;
}
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v3 06/11] leds: trigger: netdev: Implement offloaded() callback
From: Rong Zhang @ 2026-07-18 17:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Thomas Weißschuh, Benson Leung, Guenter Roeck,
Marek Behún, Mark Pearson, Derek J. Clark, Hans de Goede,
Ilpo Järvinen, Ike Panhc
Cc: Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86, Rong Zhang
In-Reply-To: <20260719-leds-trigger-hw-changed-v3-0-5fb55722e36e@rong.moe>
"netdev" can run in hardware control according to hardware capabilities
and trigger options.
Implement offloaded() callback to provide its hardware control state to
the LED core, and document the relation between the custom "offloaded"
attribute and the generic "trigger_may_offload" attribute.
Signed-off-by: Rong Zhang <i@rong.moe>
---
Changes in v3:
- Do not deprecate netdev's "offloaded" attribute (thanks Thomas
Weißschuh)
- Document the relation between the custom "offloaded" attribute and the
generic "trigger_may_offload" attribute (ditto)
---
Documentation/ABI/testing/sysfs-class-led | 3 +++
Documentation/ABI/testing/sysfs-class-led-trigger-netdev | 3 +++
drivers/leds/trigger/ledtrig-netdev.c | 8 ++++++++
3 files changed, 14 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led
index b61fc2e71bd3..7dc95f7a3505 100644
--- a/Documentation/ABI/testing/sysfs-class-led
+++ b/Documentation/ABI/testing/sysfs-class-led
@@ -100,6 +100,9 @@ Description:
- `[foo_trigger]`: the trigger is selected and offloaded to
hardware.
+ The "netdev" trigger also provides a custom attribute to
+ indicate its state, see `/sys/class/leds/<led>/offloaded`.
+
What: /sys/class/leds/<led>/inverted
Date: January 2011
KernelVersion: 2.6.38
diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
index ed46b37ab8a2..a5146ea1e3e6 100644
--- a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
@@ -75,6 +75,9 @@ Description:
If 1, the LED blinking in requested mode is offloaded to
hardware.
+ LED trigger core also provides a generic attribute for this
+ purpose, see `/sys/class/leds/<led>/trigger_may_offload`.
+
What: /sys/class/leds/<led>/link_10
Date: Jun 2023
KernelVersion: 6.5
diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c
index 64c078e997f2..a26109ca4b1c 100644
--- a/drivers/leds/trigger/ledtrig-netdev.c
+++ b/drivers/leds/trigger/ledtrig-netdev.c
@@ -754,10 +754,18 @@ static void netdev_trig_deactivate(struct led_classdev *led_cdev)
kfree(trigger_data);
}
+static bool netdev_trig_offloaded(struct led_classdev *led_cdev)
+{
+ struct led_netdev_data *trigger_data = led_get_trigger_data(led_cdev);
+
+ return trigger_data->hw_control;
+}
+
static struct led_trigger netdev_led_trigger = {
.name = "netdev",
.activate = netdev_trig_activate,
.deactivate = netdev_trig_deactivate,
+ .offloaded = netdev_trig_offloaded,
.groups = netdev_trig_groups,
};
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v3 05/11] leds: turris-omnia: trigger: Implement offloaded() and declare hw_control_trigger
From: Rong Zhang @ 2026-07-18 17:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Thomas Weißschuh, Benson Leung, Guenter Roeck,
Marek Behún, Mark Pearson, Derek J. Clark, Hans de Goede,
Ilpo Järvinen, Ike Panhc
Cc: Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86, Rong Zhang
In-Reply-To: <20260719-leds-trigger-hw-changed-v3-0-5fb55722e36e@rong.moe>
"omnia-mcu" is a private hardware control trigger which always stays in
hardware control mode. Implement offloaded() callback with its return
value to be always true to reflect this.
Meanwhile, declare it as a hardware control trigger as it's forgotten
before.
Signed-off-by: Rong Zhang <i@rong.moe>
---
drivers/leds/leds-turris-omnia.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/leds/leds-turris-omnia.c b/drivers/leds/leds-turris-omnia.c
index ed6a47bbb44f..32d40d176d3f 100644
--- a/drivers/leds/leds-turris-omnia.c
+++ b/drivers/leds/leds-turris-omnia.c
@@ -195,10 +195,16 @@ static void omnia_hwtrig_deactivate(struct led_classdev *cdev)
err);
}
+static bool omnia_hwtrig_offloaded(struct led_classdev *cdev)
+{
+ return true;
+}
+
static struct led_trigger omnia_hw_trigger = {
.name = "omnia-mcu",
.activate = omnia_hwtrig_activate,
.deactivate = omnia_hwtrig_deactivate,
+ .offloaded = omnia_hwtrig_offloaded,
.trigger_type = &omnia_hw_trigger_type,
};
@@ -251,6 +257,7 @@ static int omnia_led_register(struct i2c_client *client, struct omnia_led *led,
* by LED class from the linux,default-trigger property.
*/
cdev->default_trigger = omnia_hw_trigger.name;
+ cdev->hw_control_trigger = omnia_hw_trigger.name;
/* Put the LED into software mode */
ret = omnia_cmd_write_u8(client, OMNIA_CMD_LED_MODE, OMNIA_CMD_LED_MODE_LED(led->reg) |
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v3 04/11] leds: cros_ec: trigger: Implement offloaded() callback
From: Rong Zhang @ 2026-07-18 17:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Thomas Weißschuh, Benson Leung, Guenter Roeck,
Marek Behún, Mark Pearson, Derek J. Clark, Hans de Goede,
Ilpo Järvinen, Ike Panhc
Cc: Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86, Rong Zhang
In-Reply-To: <20260719-leds-trigger-hw-changed-v3-0-5fb55722e36e@rong.moe>
"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.
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Rong Zhang <i@rong.moe>
---
drivers/leds/leds-cros_ec.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/leds/leds-cros_ec.c b/drivers/leds/leds-cros_ec.c
index 1844d0cd5f52..6db83d015277 100644
--- a/drivers/leds/leds-cros_ec.c
+++ b/drivers/leds/leds-cros_ec.c
@@ -85,12 +85,18 @@ static int cros_ec_led_trigger_activate(struct led_classdev *led_cdev)
return cros_ec_led_send_cmd(priv->cros_ec, &arg);
}
+static bool cros_ec_led_trigger_offloaded(struct led_classdev *led_cdev)
+{
+ return true;
+}
+
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,
};
static int cros_ec_led_brightness_set_blocking(struct led_classdev *led_cdev,
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v3 03/11] leds: trigger: Add offloaded() callback and provide trigger_may_offload attribute
From: Rong Zhang @ 2026-07-18 17:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Thomas Weißschuh, Benson Leung, Guenter Roeck,
Marek Behún, Mark Pearson, Derek J. Clark, Hans de Goede,
Ilpo Järvinen, Ike Panhc
Cc: Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86, Rong Zhang
In-Reply-To: <20260719-leds-trigger-hw-changed-v3-0-5fb55722e36e@rong.moe>
There are multiple triggers implementing hardware control. However, the
LED trigger core doesn't really know the hardware control (offloaded)
state since the coordination is done directly between the trigger and
the LED driver. It can only assume private triggers as offloaded and
generic ones as not offloaded.
Add an offloaded() callback so that triggers can report their offloaded
states to the LED trigger core. When unimplemented, it defaults to true
for private triggers and false for generic ones to keep the current
behavior unchanged.
With that, provide a new attribute "trigger_may_offload", so that
userspace can determine:
- if the LED device supports hardware control (supported => visible)
- which trigger is the hardware control trigger selected by the LED
device
- if the trigger is selected ("<foo_trigger>")
- if the trigger is offloaded ("[foo_trigger]")
Note: the documentation describes the attribute as "returning a list"
despite the LED core currently only supports one hardware control
trigger per LED device. This is intentional to make the attribute
extensible in the future without breaking userspace.
Signed-off-by: Rong Zhang <i@rong.moe>
---
Changes in v3:
- Rearrange the series so that the code using the offloaded() callback is
introduced before the driver implementation (thanks Thomas Weißschuh)
- Reword documentation (ditto)
- Adopt guard() and lockdep (ditto)
- Adopt __led_trigger_is_hw_controlled() from newly-integrated PATCH 1
---
Documentation/ABI/testing/sysfs-class-led | 22 ++++++++++++++++++++++
Documentation/leds/leds-class.rst | 20 ++++++++++++++++++++
drivers/leds/led-class.c | 22 ++++++++++++++++++++++
drivers/leds/led-triggers.c | 29 +++++++++++++++++++++++++++++
drivers/leds/leds.h | 2 ++
include/linux/leds.h | 1 +
6 files changed, 96 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led
index d4c918cc11a1..b61fc2e71bd3 100644
--- a/Documentation/ABI/testing/sysfs-class-led
+++ b/Documentation/ABI/testing/sysfs-class-led
@@ -78,6 +78,28 @@ Description:
(which would often be configured in the device tree for the
hardware).
+What: /sys/class/leds/<led>/trigger_may_offload
+Date: July 2026
+KernelVersion: 7.3
+Contact: linux-leds@vger.kernel.org
+Description:
+ Names and states of triggers that may be offloaded to hardware.
+ Such triggers are also called "hardware control trigger" in some
+ context.
+
+ Only exists when the LED supports trigger offload.
+
+ Reading this file returns a list of triggers that are capable to
+ be offloaded. The optional brackets around the trigger name
+ indicate the state of the current trigger:
+
+ - `foo_trigger`: the trigger is not selected.
+ - `<foo_trigger>`: the trigger is selected, but falls back to
+ software blink for some reason (e.g., incompatible trigger
+ parameters)
+ - `[foo_trigger]`: the trigger is selected and offloaded to
+ hardware.
+
What: /sys/class/leds/<led>/inverted
Date: January 2011
KernelVersion: 2.6.38
diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst
index 3913966cfdac..2d41a6db602c 100644
--- a/Documentation/leds/leds-class.rst
+++ b/Documentation/leds/leds-class.rst
@@ -242,6 +242,9 @@ ops and needs to declare specific support for the supported triggers.
With hw control we refer to the LED driven by hardware.
+A sysfs attribute `trigger_may_offload` is provided for userspace to
+query supported triggers and their states.
+
LED driver must define the following value to support hw control:
- hw_control_trigger:
@@ -298,6 +301,15 @@ LED driver must implement the following API to support hw control:
Returns a pointer to a struct device or NULL if nothing
is currently attached.
+LED trigger should implement the following API to indicate hw control:
+ - offloaded:
+ return a boolean indicating if the trigger is currently
+ offloaded to hardware.
+
+ If a trigger doesn't implement this callback, the default
+ value will be true for private triggers and false for generic
+ ones.
+
LED driver can activate additional modes by default to workaround the
impossibility of supporting each different mode on the supported trigger.
Examples are hardcoding the blink speed to a set interval, enable special
@@ -311,6 +323,14 @@ the end use hw_control_set to activate hw control.
A trigger can use hw_control_get to check if a LED is already in hw control
and init their flags.
+Alternatively, a private trigger can be implemented along with the LED driver if
+the LED's hardware control doesn't fit any generic trigger. To associate the
+private trigger with the LED classdev, their `trigger_type` must be the same. To
+declare that the private trigger provides hardware control for the associated
+LED classdev, set the `hw_control_trigger` string to the trigger's name. Since
+both the LED classdev and the private trigger are in the same LED driver, it's
+not necessary for them to coordinate via `hw_control_*` callbacks.
+
When the LED is in hw control, no software blink is possible and doing so
will effectively disable hw control.
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index ab61e41a00a3..2460fcf0c469 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -96,8 +96,30 @@ static const struct bin_attribute *const led_trigger_bin_attrs[] = {
&bin_attr_trigger,
NULL,
};
+
+static DEVICE_ATTR_RO(trigger_may_offload);
+static struct attribute *led_trigger_attrs[] = {
+ &dev_attr_trigger_may_offload.attr,
+ NULL
+};
+
+static umode_t led_trigger_is_visible(struct kobject *kobj,
+ struct attribute *attr,
+ int idx)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+
+ if (attr == &dev_attr_trigger_may_offload.attr)
+ return led_cdev->hw_control_trigger ? attr->mode : 0;
+
+ return attr->mode;
+}
+
static const struct attribute_group led_trigger_group = {
.bin_attrs = led_trigger_bin_attrs,
+ .attrs = led_trigger_attrs,
+ .is_visible = led_trigger_is_visible,
};
#endif
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 804a04b326c4..c3c41ef40f01 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -42,6 +42,9 @@ static bool __led_trigger_is_hw_controlled(struct led_classdev *led_cdev)
if (!led_cdev->trigger)
return false;
+ if (led_cdev->trigger->offloaded)
+ return led_cdev->trigger->offloaded(led_cdev);
+
return led_cdev->trigger->trigger_type;
}
@@ -341,6 +344,32 @@ void led_trigger_set_default(struct led_classdev *led_cdev)
}
EXPORT_SYMBOL_GPL(led_trigger_set_default);
+ssize_t trigger_may_offload_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_trigger *trig;
+ bool hit, offloaded;
+ int len;
+
+ guard(mutex)(&led_cdev->led_access);
+ guard(rwsem_read)(&led_cdev->trigger_lock);
+
+ trig = led_cdev->trigger;
+
+ offloaded = __led_trigger_is_hw_controlled(led_cdev);
+ hit = offloaded || (trig && !strcmp(led_cdev->hw_control_trigger, trig->name));
+
+ /* [offloaded] <active_but_not_offloaded> inactive */
+ len = sysfs_emit(buf, "%s%s%s\n",
+ offloaded ? "[" : (hit ? "<" : ""),
+ led_cdev->hw_control_trigger,
+ offloaded ? "]" : (hit ? ">" : ""));
+
+ return len;
+}
+EXPORT_SYMBOL_GPL(trigger_may_offload_show);
+
/* LED Trigger Interface */
int led_trigger_register(struct led_trigger *trig)
diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
index bee46651e068..b08a289397e4 100644
--- a/drivers/leds/leds.h
+++ b/drivers/leds/leds.h
@@ -27,6 +27,8 @@ ssize_t led_trigger_read(struct file *filp, struct kobject *kobj,
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);
+ssize_t trigger_may_offload_show(struct device *dev,
+ struct device_attribute *attr, char *buf);
extern struct rw_semaphore leds_list_lock;
extern struct list_head leds_list;
diff --git a/include/linux/leds.h b/include/linux/leds.h
index d7d3dd905432..cc664da33e94 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -485,6 +485,7 @@ struct led_trigger {
const char *name;
int (*activate)(struct led_classdev *led_cdev);
void (*deactivate)(struct led_classdev *led_cdev);
+ bool (*offloaded)(struct led_classdev *led_cdev);
/* Brightness set by led_trigger_event */
enum led_brightness brightness;
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v3 02/11] leds: class: Remove hardware control trigger when writing brightness
From: Rong Zhang @ 2026-07-18 17:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Thomas Weißschuh, Benson Leung, Guenter Roeck,
Marek Behún, Mark Pearson, Derek J. Clark, Hans de Goede,
Ilpo Järvinen, Ike Panhc
Cc: Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86, Rong Zhang
In-Reply-To: <20260719-leds-trigger-hw-changed-v3-0-5fb55722e36e@rong.moe>
Since commit b819dc7d8fb2 ("leds: core: Report ENODATA for brightness of
hardware controlled LED"), the brightness attribute becomes write-only
when the LED is controlled fully by the hardware. A write-only attribute
is very confusing.
Moreover, most LED drivers set hardware brightness innocently with the
side effect of disabling hardware control, but the hardware control
trigger remains active, resulting in the software and hardware being out
of sync.
Fix it by removing the hardware control trigger when writing the
brightness attribute.
This should also match the semantics of hardware control:
When the LED is in hw control, no software blink is possible and
doing so will effectively disable hw control.
Fixes: b819dc7d8fb2 ("leds: core: Report ENODATA for brightness of hardware controlled LED")
Signed-off-by: Rong Zhang <i@rong.moe>
---
Changes in v3:
- New patch in the series, integrated from https://lore.kernel.org/all/20260712-leds-hw-control-brightness-set-v1-1-1de593b09d26@rong.moe/
- The following patches will improve __led_trigger_is_hw_controlled()
to include offloaded generic triggers and take the advantage of it
---
drivers/leds/led-class.c | 3 +++
drivers/leds/led-triggers.c | 9 +++++++++
include/linux/leds.h | 2 ++
3 files changed, 14 insertions(+)
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 1b8b688aaaaf..ab61e41a00a3 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -64,6 +64,9 @@ static ssize_t brightness_store(struct device *dev,
if (state == LED_OFF)
led_trigger_remove(led_cdev);
+ else
+ led_trigger_remove_hw_control(led_cdev);
+
led_set_brightness(led_cdev, state);
ret = size;
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index bf2543538ed0..804a04b326c4 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -287,6 +287,15 @@ void led_trigger_remove(struct led_classdev *led_cdev)
}
EXPORT_SYMBOL_GPL(led_trigger_remove);
+void led_trigger_remove_hw_control(struct led_classdev *led_cdev)
+{
+ guard(rwsem_write)(&led_cdev->trigger_lock);
+
+ if (__led_trigger_is_hw_controlled(led_cdev))
+ led_trigger_set(led_cdev, NULL);
+}
+EXPORT_SYMBOL_GPL(led_trigger_remove_hw_control);
+
static bool led_match_default_trigger(struct led_classdev *led_cdev,
struct led_trigger *trig)
{
diff --git a/include/linux/leds.h b/include/linux/leds.h
index a630f5a79f6b..d7d3dd905432 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -533,6 +533,7 @@ void led_trigger_blink_oneshot(struct led_trigger *trigger,
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);
+void led_trigger_remove_hw_control(struct led_classdev *led_cdev);
bool led_trigger_is_hw_controlled(struct led_classdev *led_cdev);
@@ -586,6 +587,7 @@ static inline int led_trigger_set(struct led_classdev *led_cdev,
}
static inline void led_trigger_remove(struct led_classdev *led_cdev) {}
+static inline void led_trigger_remove_hw_control(struct led_classdev *led_cdev) {}
static inline bool led_trigger_is_hw_controlled(struct led_classdev *led_cdev)
{
--
2.53.0
^ permalink raw reply related
* [PATCH RFC v3 01/11] leds: Move led_trigger_is_hw_controlled() to the right place
From: Rong Zhang @ 2026-07-18 17:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Thomas Weißschuh, Benson Leung, Guenter Roeck,
Marek Behún, Mark Pearson, Derek J. Clark, Hans de Goede,
Ilpo Järvinen, Ike Panhc
Cc: Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86, Rong Zhang
In-Reply-To: <20260719-leds-trigger-hw-changed-v3-0-5fb55722e36e@rong.moe>
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")
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 a51b0ed53886..1b8b688aaaaf 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;
+}
+
+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 b16b803cc1ac..a630f5a79f6b 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.53.0
^ permalink raw reply related
* [PATCH RFC v3 00/11] leds: Add support for hardware-initiated hardware control trigger transition
From: Rong Zhang @ 2026-07-18 17:05 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Thomas Weißschuh, Benson Leung, Guenter Roeck,
Marek Behún, Mark Pearson, Derek J. Clark, Hans de Goede,
Ilpo Järvinen, Ike Panhc
Cc: Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86, Rong Zhang
Some laptops can tune their keyboard backlight according to ambient
light sensors (auto mode). This capability is essentially a hardware
control trigger. Meanwhile, such laptops also offer a shrotcut for
cycling through brightness levels and auto mode. For example, on
ThinkBook, pressing Fn+Space ("shortcut") cycles keyboard backlight
levels in the following sequence:
1 => 2 => 0 => auto => 1 ...
Recent ThinkPad models should have similar sequence too.
However, there are some issues preventing us from using a private
hardware control trigger:
1. We want a mechanism to tell userspace which trigger is the hardware
control one, so that userspace can determine if auto mode is on/off,
as well as turing it on/off programmatically without obtaining the
trigger's name via other channels
2. Writing brightness has the side effect of disabling hardware control,
but the hardware control trigger remains active, resulting in the
software and hardware being out of sync. Most LED drivers that
supports hardware control also suffer from the same issue
3. Turing on/off auto mode via the shortcut cannot activate/deactivate
the corresponding hardware control trigger, making the software state
out of sync
4. Even with #3 solved, deactivating the hardware control trigger has
the side effect of emitting LED_OFF, breaking the shortcut cycle,
especially "auto => 1"
This RFC series tries to demonstrate a path on solving these issues:
- Introduce an attribute "trigger_may_offload", so that userspace can
determine:
- if the LED device supports hardware control (supported => visible)
- which trigger is the hardware control trigger selected by the LED
device
- if the trigger is selected ("<foo_trigger>")
- if the trigger is offloaded ("[foo_trigger]")
- A callback offloaded() is added so that LED triggers can report
their hardware control state
- Remove hardware control trigger when writing brightness
- Add led_trigger_notify_hw_control_changed() interface, so that LED
drivers can notify the LED core about hardware-initiated hardware
control transitions. The LED core will then determine if the
transition is allowed and switching between "none" (i.e., no trigger)
and the device's private trigger accordingly
- This capability is restricted to the device's private trigger. If
the current trigger is neither the private trigger nor "none", no
transition will be made
- This interface is gated behind Kconfig LEDS_TRIGGERS_HW_CHANGED and
LED device flag LED_TRIG_HW_CHANGED
- Tune the logic of trigger deactivation so that it won't emit LED_OFF
when the deactivation is triggered by hardware
The last three patches are included in the RFC series to demonstrate how
to these interfaces are supposed to be utilized, so that ideapad-laptop
can expose the auto mode of ThinkBook's keyboard backlight. They can be
submitted separately once the dust settles, if preferred.
[ Summary of other approaches ]
< custom attribute >
Pros:
- simplicity, KISS
- no need to touch the LED core
- extensible as long as it has a sensor-neutral name
- a sensor-related name could potentially lead to a mess if a future
device implements auto mode based on multiple different sensors
Cons:
- must have zero influence on brightness_set[_blocking] callbacks
in order not to break triggers
- potential interference with triggers and the brightness attribute,
can't solve #2
- weird semantic (an attribute other than "brightness" and "trigger"
changes the brightness)
< private hardware control trigger (this series) >
Pros:
- mutually exclusive with other triggers and the brightness attribute
(hence less chaos)
- semantic correctness
- acts as an aggregate switch to turn on/off auto mode even a future
device implements auto mode based on multiple different sensors
- extensibility (through trigger attributes)
Cons:
- complexity
[ Previous discussion threads ]
https://lore.kernel.org/r/08580ec5-1d7b-4612-8a3f-75bc2f40aad2@app.fastmail.com
https://lore.kernel.org/r/1dbfcf656cdb4af0299f90d7426d2ec7e2b8ac9e.camel@rong.moe
Signed-off-by: Rong Zhang <i@rong.moe>
---
Changes in v3:
- Integrate https://lore.kernel.org/all/20260712-leds-hw-control-brightness-set-v1-1-1de593b09d26@rong.moe/
into the series
- Adopt __led_trigger_is_hw_controlled() in the rest of the series
- Rearrange the series so that the code using the offloaded() callback is
introduced before the driver implementation (thanks Thomas Weißschuh)
- Reword documentations and commit messages (ditto)
- Adopt guard() and lockdep (ditto)
- Address concerns from Sashiko
- Fix a race condition in ideapad_kbd_bl_led_cdev_brightness_set()
- Fix trigger re-registration of ideapad_kbd_bl_auto_trigger
- https://sashiko.dev/#/patchset/20260618-leds-trigger-hw-changed-v2-0-c28c44053cf3%40rong.moe
- Make registration failures of ideapad_kbd_bl_auto_trigger non-fatal
- Link to v2: https://patch.msgid.link/20260618-leds-trigger-hw-changed-v2-0-c28c44053cf3@rong.moe
Changes in v2:
- Restrict the led_trigger_notify_hw_control_changed() interface to
private triggers only
- Drop PATCH v1 1/9 ("leds: Load trigger modules on-demand if used as
hw control trigger"), not relavant any more
- Gate the led_trigger_notify_hw_control_changed() interface behind
Kconfig LEDS_TRIGGERS_HW_CHANGED and LED device flag
LED_TRIG_HW_CHANGED
- Fix lock ordering inversion
- ideapad-laptop:
- Only call led_trigger_notify_hw_control_changed() when needed
- Serialize keyboard backlight notifications
- Reword commit messages and documentations
- Link to v1: https://patch.msgid.link/20260227190617.271388-1-i@rong.moe
---
Rong Zhang (11):
leds: Move led_trigger_is_hw_controlled() to the right place
leds: class: Remove hardware control trigger when writing brightness
leds: trigger: Add offloaded() callback and provide trigger_may_offload attribute
leds: cros_ec: trigger: Implement offloaded() callback
leds: turris-omnia: trigger: Implement offloaded() and declare hw_control_trigger
leds: trigger: netdev: Implement offloaded() callback
leds: trigger: Enforce strict checks in led_trigger_is_hw_controlled()
leds: trigger: Add led_trigger_notify_hw_control_changed() interface
platform/x86: ideapad-laptop: Decouple hardware & classdev brightness for keyboard backlight
platform/x86: ideapad-laptop: Serialize keyboard backlight notifications
platform/x86: ideapad-laptop: Fully support auto keyboard backlight
Documentation/ABI/testing/sysfs-class-led | 25 ++
.../ABI/testing/sysfs-class-led-trigger-netdev | 3 +
Documentation/leds/leds-class.rst | 72 ++++++
drivers/leds/led-class.c | 35 ++-
drivers/leds/led-triggers.c | 146 +++++++++++-
drivers/leds/leds-cros_ec.c | 6 +
drivers/leds/leds-turris-omnia.c | 7 +
drivers/leds/leds.h | 2 +
drivers/leds/trigger/Kconfig | 9 +
drivers/leds/trigger/ledtrig-netdev.c | 8 +
drivers/platform/x86/lenovo/Kconfig | 1 +
drivers/platform/x86/lenovo/ideapad-laptop.c | 264 ++++++++++++++++-----
include/linux/leds.h | 19 ++
13 files changed, 532 insertions(+), 65 deletions(-)
---
base-commit: 1229e2e57a5c2980ccd457b9b53ea0eed5a22ab3
change-id: 20260506-leds-trigger-hw-changed-96a62188cbdf
Thanks,
Rong
^ permalink raw reply
* Re: [PATCH v2] PCI: Move pci_dev->is_busmaster into priv_flags
From: Maurice Hieronymus @ 2026-07-18 17:02 UTC (permalink / raw)
To: Lukas Wunner, Maurice Hieronymus
Cc: Edward Cree, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Bjorn Helgaas, Justin Tee, Paul Ely,
James E.J. Bottomley, Martin K. Petersen, Juergen Gross,
Stefano Stabellini, Oleksandr Tyshchenko, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, Daniel Almeida,
Tamir Duberstein, Alexandre Courbot, Onur Özkan,
Borislav Petkov, Tony Luck, Danilo Krummrich, rust-for-linux,
netdev, linux-net-drivers, linux-kernel, linux-pci, linux-scsi,
xen-devel, linux-edac
In-Reply-To: <alcSjoypegNolW48@wunner.de>
On Wed Jul 15, 2026 at 6:54 AM CEST, Lukas Wunner wrote:
> pci_dev_assign_busmaster() should not have public visibility.
> Drivers should really use pci_set_master() / pci_clear_master()
> and nothing else.
>
> It seems Xen is the only one in the tree which needs this:
>
>> +++ b/drivers/xen/xen-pciback/pciback_ops.c
>> @@ -125,14 +125,14 @@ void xen_pcibk_reset_device(struct pci_dev *dev)
>> if (pci_is_enabled(dev))
>> pci_disable_device(dev);
>>
>> - dev->is_busmaster = 0;
>> + pci_dev_assign_busmaster(dev, false);
>> } else {
>> pci_read_config_word(dev, PCI_COMMAND, &cmd);
>> if (cmd & (PCI_COMMAND_INVALIDATE)) {
>> cmd &= ~(PCI_COMMAND_INVALIDATE);
>> pci_write_config_word(dev, PCI_COMMAND, cmd);
>>
>> - dev->is_busmaster = 0;
>> + pci_dev_assign_busmaster(dev, false);
>> }
>> }
>> }
>
> Please change these direct assignments to pci_clear_master(),
> preferably in a separate patch to ease bisecting if anything
> breaks.
This conversion does not preserve behavior. The direct assignments
clear only the software flag, while pci_clear_master() also clears
PCI_COMMAND_MASTER in config space.
I am not an expert on xen devices. That's why I want to clarify first
that this does not break anything. Especially since commit
7681f31ec9cd ("xen/pciback: Don't disable PCI_COMMAND on PCI device
reset.") deliberately removed the PCI_COMMAND write right above the
first assignment, and pci_clear_master() would reintroduce a
PCI_COMMAND write there.
Best,
Maurice
^ permalink raw reply
* [PATCH net-next 2/2] igb: read SFP module EEPROM through igb_read_sfp_data_byte
From: Pawel Dembicki @ 2026-07-18 16:56 UTC (permalink / raw)
To: netdev
Cc: Pawel Dembicki, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
intel-wired-lan, linux-kernel
igb_get_module_info() and igb_get_module_eeprom() use
igb_read_phy_reg_i2c(), which accesses the external PHY register space.
On designs with an external SGMII PHY this returns PHY register contents
instead of the SFP module EEPROM requested by ethtool -m.
Use igb_read_sfp_data_byte() for module EEPROM reads. The legacy
ethtool module EEPROM offset space maps directly to the I210 I2CCMD
module address space: offsets 0x000-0x0ff address the SFP base EEPROM
and offsets 0x100-0x1ff address the diagnostics EEPROM.
Assisted-by: Codex:GPT-5
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 40 ++++++--------------
1 file changed, 12 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 65014a54a6d1..0fb15bd940d7 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -3209,7 +3209,7 @@ static int igb_get_module_info(struct net_device *netdev,
struct igb_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = &adapter->hw;
u32 status = 0;
- u16 sff8472_rev, addr_mode;
+ u8 sff8472_rev, addr_mode;
bool page_swap = false;
if ((hw->phy.media_type == e1000_media_type_copper) ||
@@ -3217,22 +3217,26 @@ static int igb_get_module_info(struct net_device *netdev,
return -EOPNOTSUPP;
/* Check whether we support SFF-8472 or not */
- status = igb_read_phy_reg_i2c(hw, IGB_SFF_8472_COMP, &sff8472_rev);
+ status = igb_read_sfp_data_byte(hw,
+ E1000_I2CCMD_SFP_DATA_ADDR(IGB_SFF_8472_COMP),
+ &sff8472_rev);
if (status)
return -EIO;
/* addressing mode is not supported */
- status = igb_read_phy_reg_i2c(hw, IGB_SFF_8472_SWAP, &addr_mode);
+ status = igb_read_sfp_data_byte(hw,
+ E1000_I2CCMD_SFP_DATA_ADDR(IGB_SFF_8472_SWAP),
+ &addr_mode);
if (status)
return -EIO;
/* addressing mode is not supported */
- if ((addr_mode & 0xFF) & IGB_SFF_ADDRESSING_MODE) {
+ if (addr_mode & IGB_SFF_ADDRESSING_MODE) {
hw_dbg("Address change required to access page 0xA2, but not supported. Please report the module type to the driver maintainers.\n");
page_swap = true;
}
- if ((sff8472_rev & 0xFF) == IGB_SFF_8472_UNSUP || page_swap) {
+ if (sff8472_rev == IGB_SFF_8472_UNSUP || page_swap) {
/* We have an SFP, but it does not support SFF-8472 */
modinfo->type = ETH_MODULE_SFF_8079;
modinfo->eeprom_len = ETH_MODULE_SFF_8079_LEN;
@@ -3251,37 +3255,17 @@ static int igb_get_module_eeprom(struct net_device *netdev,
struct igb_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = &adapter->hw;
u32 status = 0;
- u16 *dataword;
- u16 first_word, last_word;
int i = 0;
if (ee->len == 0)
return -EINVAL;
- first_word = ee->offset >> 1;
- last_word = (ee->offset + ee->len - 1) >> 1;
-
- dataword = kmalloc_array(last_word - first_word + 1, sizeof(u16),
- GFP_KERNEL);
- if (!dataword)
- return -ENOMEM;
-
- /* Read EEPROM block, SFF-8079/SFF-8472, word at a time */
- for (i = 0; i < last_word - first_word + 1; i++) {
- status = igb_read_phy_reg_i2c(hw, (first_word + i) * 2,
- &dataword[i]);
- if (status) {
- /* Error occurred while reading module */
- kfree(dataword);
+ for (i = 0; i < ee->len; i++) {
+ status = igb_read_sfp_data_byte(hw, ee->offset + i, &data[i]);
+ if (status)
return -EIO;
- }
-
- be16_to_cpus(&dataword[i]);
}
- memcpy(data, (u8 *)dataword + (ee->offset & 1), ee->len);
- kfree(dataword);
-
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH net-next 1/2] igb: detect M88E1112 100BASE-FX SGMII mode
From: Pawel Dembicki @ 2026-07-18 16:52 UTC (permalink / raw)
To: netdev
Cc: Pawel Dembicki, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
intel-wired-lan, linux-kernel
The M88E1112 can be strapped or EEPROM-configured to bridge SGMII
to 100BASE-FX. In this mode the driver still needs the SGMII PHY
register access path to identify the external PHY, but the MAC link
setup must follow the SERDES media path rather than copper setup.
Decode the M88E1112 MAC Control 1 mode field and switch the I210
media type and physical interface setup callback when the PHY reports
100BASE-FX mode.
The driver only observes the Marvell mode. It does not program the
88E1112 registers or its EEPROM. The board must configure it
through firmware or straps before probe.
Assisted-by: Codex:GPT-5
Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
---
drivers/net/ethernet/intel/igb/e1000_82575.c | 12 +++++++++++-
drivers/net/ethernet/intel/igb/e1000_defines.h | 1 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c b/drivers/net/ethernet/intel/igb/e1000_82575.c
index 44a85ad749a4..72c42d9d6f47 100644
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -264,9 +264,19 @@ static s32 igb_init_phy_params_82575(struct e1000_hw *hw)
data = FIELD_GET(E1000_M88E1112_MAC_CTRL_1_MODE_MASK,
data);
if (data == E1000_M88E1112_AUTO_COPPER_SGMII ||
- data == E1000_M88E1112_AUTO_COPPER_BASEX)
+ data == E1000_M88E1112_AUTO_COPPER_BASEX) {
hw->mac.ops.check_for_link =
igb_check_for_link_media_swap;
+ } else if (data == E1000_M88E1112_100BASE_FX) {
+ /* The driver only detects this strap/EEPROM
+ * mode. 88E1112 register and EEPROM setup must
+ * be done outside igb before probe/reset.
+ */
+ hw->phy.media_type =
+ e1000_media_type_internal_serdes;
+ hw->mac.ops.setup_physical_interface =
+ igb_setup_serdes_link_82575;
+ }
}
if (phy->id == M88E1512_E_PHY_ID) {
ret_val = igb_initialize_M88E1512_phy(hw);
diff --git a/drivers/net/ethernet/intel/igb/e1000_defines.h b/drivers/net/ethernet/intel/igb/e1000_defines.h
index 7e6f9aa2d57b..25104328eae6 100644
--- a/drivers/net/ethernet/intel/igb/e1000_defines.h
+++ b/drivers/net/ethernet/intel/igb/e1000_defines.h
@@ -615,6 +615,7 @@
#define E1000_MEDIA_PORT_COPPER 1
#define E1000_MEDIA_PORT_OTHER 2
+#define E1000_M88E1112_100BASE_FX 0x0
#define E1000_M88E1112_AUTO_COPPER_SGMII 0x2
#define E1000_M88E1112_AUTO_COPPER_BASEX 0x3
#define E1000_M88E1112_STATUS_LINK 0x0004 /* Interface Link Bit */
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net v3] net: dpaa: fix mode setting
From: Christian Zigotzky @ 2026-07-18 16:31 UTC (permalink / raw)
To: Sean Anderson, Michael Walle, Madalin Bucur, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Christian Zigotzky
Cc: netdev, linux-kernel, linuxppc-dev, R.T.Dickinson, mad skateman,
Damien Stewart
In-Reply-To: <4f7497cf-83ed-47cd-2e7b-d06ebe319b61@linux.dev>
On 17/07/26 23:10, Sean Anderson wrote:
> On 7/17/26 09:20, Michael Walle wrote:
>> Before converting to the phylink interface, the init function would have
>> set a non-reserved I/F mode in the maccfg2 register. After converting to
>> phylink, 0 is written as mode, which is a reserved value (although it's
>> the hardware default). Without a valid mode, a SGMII link is never
>> established between the MAC and the PHY and thus .link_up() is never
>> called which could set the correct mode according to the actual speed.
>>
>> Fix it by setting the maximum speed of the phy_interface_t in use in
>> .mac_config() - just like the driver did before the phylink conversion.
>>
>> Fixes: 5d93cfcf7360 ("net: dpaa: Convert to phylink")
>> Suggested-by: Sean Anderson <sean.anderson@linux.dev>
>> Signed-off-by: Michael Walle <mwalle@kernel.org>
>> ---
>> I didn't grab Sean's Rb tag as this is somewhat different.
>>
>> Changes in v3:
>> - keep the mode setting also in .adjust_link().
>> - reword the commit message, to be (hopefully) more precise
>> - Link to v2:
>> https://lore.kernel.org/r/20260710143430.2276141-1-mwalle@kernel.org/
>>
>> Changes in v2:
>> - the setting is/was based on the maximum speed, not the current
>> speed. thus, move the setting into mac_config().
>> - Link to v1:
>> https://lore.kernel.org/r/20260706121011.1948906-1-mwalle@kernel.org/
>>
>> .../net/ethernet/freescale/fman/fman_dtsec.c | 17 ++++++++++++-----
>> 1 file changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/freescale/fman/fman_dtsec.c
>> b/drivers/net/ethernet/freescale/fman/fman_dtsec.c
>> index fe35703c509e..b8d70c0ecb6c 100644
>> --- a/drivers/net/ethernet/freescale/fman/fman_dtsec.c
>> +++ b/drivers/net/ethernet/freescale/fman/fman_dtsec.c
>> @@ -900,22 +900,28 @@ static void dtsec_mac_config(struct
>> phylink_config *config, unsigned int mode,
>> {
>> struct mac_device *mac_dev = fman_config_to_mac(config);
>> struct dtsec_regs __iomem *regs = mac_dev->fman_mac->regs;
>> - u32 tmp;
>> + u32 ecntrl, maccfg2;
>> +
>> + maccfg2 = ioread32be(®s->maccfg2);
>> + maccfg2 &= ~(MACCFG2_NIBBLE_MODE | MACCFG2_BYTE_MODE);
>> switch (state->interface) {
>> case PHY_INTERFACE_MODE_RMII:
>> - tmp = DTSEC_ECNTRL_RMM;
>> + ecntrl = DTSEC_ECNTRL_RMM;
>> + maccfg2 |= MACCFG2_NIBBLE_MODE;
>> break;
>> case PHY_INTERFACE_MODE_RGMII:
>> case PHY_INTERFACE_MODE_RGMII_ID:
>> case PHY_INTERFACE_MODE_RGMII_RXID:
>> case PHY_INTERFACE_MODE_RGMII_TXID:
>> - tmp = DTSEC_ECNTRL_GMIIM | DTSEC_ECNTRL_RPM;
>> + ecntrl = DTSEC_ECNTRL_GMIIM | DTSEC_ECNTRL_RPM;
>> + maccfg2 |= MACCFG2_BYTE_MODE;
>> break;
>> case PHY_INTERFACE_MODE_SGMII:
>> case PHY_INTERFACE_MODE_1000BASEX:
>> case PHY_INTERFACE_MODE_2500BASEX:
>> - tmp = DTSEC_ECNTRL_TBIM | DTSEC_ECNTRL_SGMIIM;
>> + ecntrl = DTSEC_ECNTRL_TBIM | DTSEC_ECNTRL_SGMIIM;
>> + maccfg2 |= MACCFG2_BYTE_MODE;
>> break;
>> default:
>> dev_warn(mac_dev->dev, "cannot configure dTSEC for %s\n",
>> @@ -923,7 +929,8 @@ static void dtsec_mac_config(struct
>> phylink_config *config, unsigned int mode,
>> return;
>> }
>> - iowrite32be(tmp, ®s->ecntrl);
>> + iowrite32be(ecntrl, ®s->ecntrl);
>> + iowrite32be(maccfg2, ®s->maccfg2);
>> }
>> static void dtsec_link_up(struct phylink_config *config, struct
>> phy_device *phy,
>
> Reviewed-by: Sean Anderson <sean.anderson@linux.dev>
>
> Christian, can you test this patch with ethernet at 100/1G speed if
> you still have
> access to those P5020/P5040 boards?
>
> https://lore.kernel.org/all/0bfc8f3d-cb62-25f4-2590-ff424adbe48a@xenosoft.de/
>
I tested the patch today. I don't see any differences.
Further information:
https://github.com/chzigotzky/kernels/releases/tag/v7.2.0-rc3-fman-dtsec-patch
Christian
--
Sent with BrassMonkey 34.2.2 (https://github.com/chzigotzky/Web-Browsers-and-Suites-for-Linux-PPC/releases/tag/BrassMonkey_34.2.2)
^ permalink raw reply
* Re: [REGRESSION][BISECTED] stmmac: suspend hangs since 1b9707e6f1a9 ("net: stmmac: enable RPS and RBU interrupts")
From: tresonic @ 2026-07-18 15:32 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Maxime Chevallier, netdev, regressions, rmk+kernel, kuba
In-Reply-To: <36957839-b03a-4403-b08e-12bbadd8bc0c@lunn.ch>
On 7/18/26 4:11 PM, Andrew Lunn wrote:
> There are two documents for you to read:
>
> https://docs.kernel.org/process/submitting-patches.html
>
> https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
>
> Since this is a fix, please use the net tree. And include a Fixes: tag
> indicating the patch which broke it.
>
>> Just commit and separately git send-email to netdev@vger.kernel.org?
>
> ./scripts/get_maintainer.pl will give you a list of email addresses.
I did your suggested change, read through the documents and hope to have
sent everything correctly :)
Thanks for your help,
Luis/tresonic
^ permalink raw reply
* [PATCH] net: stmmac: dwmac4: mask interrupts before stopping DMA in suspend
From: Luis Lang @ 2026-07-18 15:27 UTC (permalink / raw)
To: netdev
Cc: Luis Lang, Andrew Lunn, Maxime Chevallier, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Maxime Coquelin, Alexandre Torgue, Russell King (Oracle),
Ovidiu Panait, Oleksij Rempel, Rohan G Thomas,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE, open list
In-Reply-To: <7941d239-e5f5-43b5-ae0f-20398221e027@mail.de>
Since commit 1b9707e6f1a9 ("net: stmmac: enable RPS and RBU
interrupts"), suspending causes an interrupt storm from the RPS
interrupt.
Fix this by adding a deinit_chan() op to stmmac_dma_ops, which
masks all default dma channel interrupts. This is called from
stmmac_stop_all_dma(), so interrupts don't trigger while suspending.
Fixes: 1b9707e6f1a9 ("net: stmmac: enable RPS and RBU interrupts")
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Luis Lang <luis.la@mail.de>
---
.../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 24 +++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/hwif.h | 4 ++++
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++
3 files changed, 32 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 829a23bdad01..23ffe1adcd0d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -106,6 +106,17 @@ static void dwmac4_dma_init_channel(struct stmmac_priv *priv,
ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
}
+static void dwmac4_dma_deinit_channel(struct stmmac_priv *priv,
+ void __iomem *ioaddr, u32 chan)
+{
+ const struct dwmac4_addrs *dwmac4_addrs = priv->plat->dwmac4_addrs;
+ u32 value;
+
+ value = readl(ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
+ value &= ~DMA_CHAN_INTR_DEFAULT_MASK;
+ writel(value, ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
+}
+
static void dwmac410_dma_init_channel(struct stmmac_priv *priv,
void __iomem *ioaddr,
struct stmmac_dma_cfg *dma_cfg, u32 chan)
@@ -125,6 +136,17 @@ static void dwmac410_dma_init_channel(struct stmmac_priv *priv,
ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
}
+static void dwmac410_dma_deinit_channel(struct stmmac_priv *priv,
+ void __iomem *ioaddr, u32 chan)
+{
+ const struct dwmac4_addrs *dwmac4_addrs = priv->plat->dwmac4_addrs;
+ u32 value;
+
+ value = readl(ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
+ value &= ~DMA_CHAN_INTR_DEFAULT_MASK_4_10;
+ writel(value, ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
+}
+
static void dwmac4_dma_init(void __iomem *ioaddr,
struct stmmac_dma_cfg *dma_cfg)
{
@@ -548,6 +570,7 @@ const struct stmmac_dma_ops dwmac4_dma_ops = {
.reset = dwmac4_dma_reset,
.init = dwmac4_dma_init,
.init_chan = dwmac4_dma_init_channel,
+ .deinit_chan = dwmac4_dma_deinit_channel,
.init_rx_chan = dwmac4_dma_init_rx_chan,
.init_tx_chan = dwmac4_dma_init_tx_chan,
.axi = dwmac4_dma_axi,
@@ -577,6 +600,7 @@ const struct stmmac_dma_ops dwmac410_dma_ops = {
.reset = dwmac4_dma_reset,
.init = dwmac4_dma_init,
.init_chan = dwmac410_dma_init_channel,
+ .deinit_chan = dwmac410_dma_deinit_channel,
.init_rx_chan = dwmac4_dma_init_rx_chan,
.init_tx_chan = dwmac4_dma_init_tx_chan,
.axi = dwmac4_dma_axi,
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index e6317b94fff7..04dafec021b4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -170,6 +170,8 @@ struct stmmac_dma_ops {
void (*init)(void __iomem *ioaddr, struct stmmac_dma_cfg *dma_cfg);
void (*init_chan)(struct stmmac_priv *priv, void __iomem *ioaddr,
struct stmmac_dma_cfg *dma_cfg, u32 chan);
+ void (*deinit_chan)(struct stmmac_priv *priv, void __iomem *ioaddr,
+ u32 chan);
void (*init_rx_chan)(struct stmmac_priv *priv, void __iomem *ioaddr,
struct stmmac_dma_cfg *dma_cfg,
dma_addr_t phy, u32 chan);
@@ -235,6 +237,8 @@ struct stmmac_dma_ops {
stmmac_do_void_callback(__priv, dma, init, __args)
#define stmmac_init_chan(__priv, __args...) \
stmmac_do_void_callback(__priv, dma, init_chan, __priv, __args)
+#define stmmac_deinit_chan(__priv, __args...) \
+ stmmac_do_void_callback(__priv, dma, deinit_chan, __priv, __args)
#define stmmac_init_rx_chan(__priv, __args...) \
stmmac_do_void_callback(__priv, dma, init_rx_chan, __priv, __args)
#define stmmac_init_tx_chan(__priv, __args...) \
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2a0d7eff88d3..af29a50ddb89 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2560,6 +2560,7 @@ static void stmmac_stop_all_dma(struct stmmac_priv *priv)
{
u8 rx_channels_count = priv->plat->rx_queues_to_use;
u8 tx_channels_count = priv->plat->tx_queues_to_use;
+ u8 dma_csr_ch = max(rx_channels_count, tx_channels_count);
u8 chan;
for (chan = 0; chan < rx_channels_count; chan++)
@@ -2567,6 +2568,9 @@ static void stmmac_stop_all_dma(struct stmmac_priv *priv)
for (chan = 0; chan < tx_channels_count; chan++)
stmmac_stop_tx_dma(priv, chan);
+
+ for (chan = 0; chan < dma_csr_ch; chan++)
+ stmmac_deinit_chan(priv, priv->ioaddr, chan);
}
/**
--
2.55.0
^ permalink raw reply related
* Re: [PATCH net-next] net/sched: sch_cake: skip clearing unused tins during rate adjustment
From: Jonas Köppeler @ 2026-07-18 15:06 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Jamal Hadi Salim, Jiri Pirko,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: cake, netdev, linux-kernel, Mike Pham
In-Reply-To: <87wluuj9ue.fsf@toke.dk>
On 7/17/26 10:31, Toke Høiland-Jørgensen wrote:
> Jonas Köppeler <j.koeppeler@tu-berlin.de> writes:
>
>> When cake_configure_rates() is called from the dequeue path with
>> rate_adjust=true, it only needs to update the rate parameters. The
>> loop that clears the unused tins is both unnecessary and harmful in
>> this path:
>>
>> - cake_clear_tin() overwrites q->cur_tin and q->cur_flow, which are
>> actively used by cake_dequeue(), corrupting the dequeue state.
>> - iterating over the unused tins and their internal queues to purge
>> packets adds needless overhead to the hot path.
>>
>> Skip the entire loop when rate_adjust is set, as neither
>> cake_clear_tin() nor the mtu_time update are needed when only the
>> rate changes.
>>
>> Fixes: 15c2715a5264 ("net/sched: sch_cake: fixup cake_mq rate adjustment for diffserv config")
>> Signed-off-by: Jonas Köppeler <j.koeppeler@tu-berlin.de>
>> Tested-by: Mike Pham <mikepham4321@gmail.com>
>
> Do you have any performance numbers to show the impact of this?
Yes, the table below shows results from a test setup using vng with
2 network namespaces, with cake/cake_mq attached in one of them:
ns1 -> cake/cake_mq -> ns2
- veth devices are configured with 8 rx/tx queues.
- cake/cake_mq is configured with a 2 Gbit rate limit.
- Running flent's rrul and tcp_nup tests with 32 TCP upstreams:
legend: qdisc mq = cake_mq; mode be = besteffort, ds3 = diffserv3
test nup = tcp_nup; base/load = idle/loaded RTT (ms); tput = Mbit/s
+---------------------+-------+------+------+-------+-------+---------+
| kernel | qdisc | mode | test | base | load | tput |
+---------------------+-------+------+------+-------+-------+---------+
| net-next | cake | be | rrul | 0.075 | 4.76 | 1473.69 |
| net-next | cake | be | nup | 0.078 | 6.23 | 1550.79 |
| net-next | cake | ds3 | rrul | 0.063 | 5.81 | 1526.75 |
| net-next | cake | ds3 | nup | 0.046 | 6.09 | 1761.45 |
+---------------------+-------+------+------+-------+-------+---------+
| net-next | mq | be | rrul | 0.810 | 11.78 | 1469.67 |
| net-next | mq | be | nup | 0.637 | 85.71 | 1243.15 |
| net-next | mq | ds3 | rrul | 0.397 | 15.28 | 1770.06 |
| net-next | mq | ds3 | nup | 0.351 | 15.98 | 1799.39 |
+---------------------+-------+------+------+-------+-------+---------+
| this patch | mq | be | rrul | 0.092 | 0.56 | 1873.40 |
| this patch | mq | be | nup | 0.109 | 1.82 | 1869.12 |
| this patch | mq | ds3 | rrul | 0.097 | 0.98 | 1866.10 |
| this patch | mq | ds3 | nup | 0.101 | 0.51 | 1861.79 |
+---------------------+-------+------+------+-------+-------+---------+
| before 15c2715a5264 | mq | be | rrul | 0.073 | 0.30 | 1895.45 |
| before 15c2715a5264 | mq | be | nup | 0.076 | 0.49 | 1905.57 |
| before 15c2715a5264 | mq | ds3 | rrul | 0.069 | 0.31 | 1896.59 |
| before 15c2715a5264 | mq | ds3 | nup | 0.058 | 0.86 | 1884.01 |
+---------------------+-------+------+------+-------+-------+---------+
Not only is p99 latency drastically reduced -- nearly matching
pre-15c2715a5264 results -- but on current upstream cake_mq,
throughput also increases as a cake mode uses more tins. This points
directly to cake_clear_tin() during reconfig as the cause, since it
clears (max_tins - cur_tins) tins each time. So the fewer tins the
current mode uses, the more get cleared on every reconfig.
Mike ran also some test on OpenWrt, on an IPQ8074A with 4 rx/tx
queues, and saw similar trends. cake_mq is configured with a 2.2 Gbit
rate limit.
Unfortunately, we only have data for 128 TCP upstreams on net-next,
and 64 TCP upstreams for 'this patch'.
+---------------------+-------+------+------+---------+----------+
| kernel | qdisc | mode | test | load | tput |
+---------------------+-------+------+------+---------+----------+
| net-next | mq | be | nup | 468.50 | 50.90 |
| net-next | mq | ds3 | nup | 355.22 | 98.21 |
| net-next | mq | ds4 | nup | 268.28 | 255.84 |
| net-next | mq | ds8 | nup | 7.48 | 2023.66 |
+---------------------+-------+------+------+---------+----------+
| this patch | mq | be | nup | 4.24 | 944.35 |
| this patch | mq | ds3 | nup | 4.27 | 937.75 |
| this patch | mq | ds4 | nup | 4.24 | 936.97 |
| this patch | mq | ds8 | nup | 4.32 | 927.89 |
+---------------------+-------+------+------+---------+----------+
This again shows the same trend: throughput increases and latency
drops as cake_mq is configured with more tins. We're still looking
into why net-next+ds8 reaches close to 2 Gbit/s, while this patch
tops out around 928 Mbit/s.
That said, this patch doesn't solve every issue yet, but it does
remove the regression introduced by commit 15c2715a5264
("net/sched: sch_cake: fixup cake_mq rate adjustment for diffserv
config").
We're continuing to look into further improvements. Let us know if
you'd like to see additional tests :)
- Jonas
>
> -Toke
^ permalink raw reply
* Re: [PATCH v2 3/8] clk: sunxi-ng: a733: Add PRCM CCU
From: Enzo Adriano @ 2026-07-18 14:46 UTC (permalink / raw)
To: Junhui Liu
Cc: Andre Przywara, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Philipp Zabel, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Richard Cochran,
Jerome Brunet, linux-clk, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel, linux-riscv, netdev
In-Reply-To: <20260711-a733-clk-v2-3-974d188cbe0c@pigmoral.tech>
Hi Junhui,
I re-reviewed patch 3 in v2 after Andre pointed out that my RFC reply lacked
a formal tag.
I compared the RFC and v2 PRCM drivers and rechecked v2 against the Allwinner
A733 User Manual V0.92, chapter 4.2.5. I checked all 11 programmable clock
definitions (register offsets and divider/mux/gate fields), all 18 bus-gate
definitions, and all 13 reset-map entries. They match the manual.
The RFC-to-v2 changes do not invalidate that check: the four R timer clocks
move from the MP helper with no M field to the P-only helper while keeping
their offsets and P/mux/gate fields unchanged, and the R PWM identifiers are
renamed while keeping their offset/mux/gate fields unchanged. I also checked
the gate-only BGRs for R-TWD, R-PPU, R-TZMA, and R-CPU-BIST; the manual defines
gate bit 0 but no reset bit for those registers, matching v2.
Reviewed-by: Enzo Adriano <enzo.adriano.code@gmail.com>
This analysis was done with AI assistance and each finding was checked against
the cited sources.
Thanks,
Enzo
^ permalink raw reply
* [PATCH net-next] net: stmmac: Simplify ioctl handling
From: Maxime Chevallier @ 2026-07-18 14:38 UTC (permalink / raw)
To: Andrew Lunn, Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni,
Simon Horman, Maxime Coquelin, Alexandre Torgue, Russell King
Cc: Maxime Chevallier, thomas.petazzoni, Alexis Lothoré, netdev,
linux-kernel, linux-arm-kernel, linux-stm32
Now that timestamping is controlled through an NDO, we can simply
call phylink_mii_ioctl() to handle ioctls.
The only functional difference is that phylink_mii_ioctl() ->
phy_mii_ioctl() can handle SIOCSHWTSTAMP, but this no longer happens
as this ioctl is not longer dispatched to the ndo_eth_ioctl().
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
Looking at this, I'm wondering if we can't just get rid of SIOCSHWTSTAMP
handling in phy_mii_ioctl(). Looks like we can ?
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2a0d7eff88d3..562d20830b94 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6371,28 +6371,17 @@ static irqreturn_t stmmac_msi_intr_rx(int irq, void *data)
* @rq: An IOCTL specific structure, that can contain a pointer to
* a proprietary structure used to pass information to the driver.
* @cmd: IOCTL command
- * Description:
- * Currently it supports the phy_mii_ioctl(...) and HW time stamping.
+ * Description: Forward the PHY ioctls to phylink
+ * Return: Zero on success or negative error code.
*/
static int stmmac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct stmmac_priv *priv = netdev_priv (dev);
- int ret = -EOPNOTSUPP;
if (!netif_running(dev))
return -EINVAL;
- switch (cmd) {
- case SIOCGMIIPHY:
- case SIOCGMIIREG:
- case SIOCSMIIREG:
- ret = phylink_mii_ioctl(priv->phylink, rq, cmd);
- break;
- default:
- break;
- }
-
- return ret;
+ return phylink_mii_ioctl(priv->phylink, rq, cmd);
}
static int stmmac_setup_tc_block_cb(enum tc_setup_type type, void *type_data,
--
2.55.0
^ permalink raw reply related
* Re: [REGRESSION][BISECTED] stmmac: suspend hangs since 1b9707e6f1a9 ("net: stmmac: enable RPS and RBU interrupts")
From: Andrew Lunn @ 2026-07-18 14:11 UTC (permalink / raw)
To: tresonic; +Cc: Maxime Chevallier, netdev, regressions, rmk+kernel, kuba
In-Reply-To: <54128253-eb77-48f5-a673-94fb65edb78f@mail.de>
> Sorry for the noob question, how would I submit this fix?
There are two documents for you to read:
https://docs.kernel.org/process/submitting-patches.html
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Since this is a fix, please use the net tree. And include a Fixes: tag
indicating the patch which broke it.
> Just commit and separately git send-email to netdev@vger.kernel.org?
./scripts/get_maintainer.pl will give you a list of email addresses.
Or take a look at
https://b4.docs.kernel.org/en/latest/contributor/prep.html
b4 automates some of the steps in producing patches, keeping track of
versions, working out who to send to etc.
Often with the kernel, the code is easy. Getting the processes correct
is harder. But we are here to help.
Andrew
^ permalink raw reply
* Re: [REGRESSION][BISECTED] stmmac: suspend hangs since 1b9707e6f1a9 ("net: stmmac: enable RPS and RBU interrupts")
From: Andrew Lunn @ 2026-07-18 14:06 UTC (permalink / raw)
To: tresonic; +Cc: netdev, regressions, rmk+kernel, kuba, Maxime Chevallier
In-Reply-To: <97d803a5-ca6e-4d4a-adc2-f97cabfded65@mail.de>
> {
> u8 rx_channels_count = priv->plat->rx_queues_to_use;
> u8 tx_channels_count = priv->plat->tx_queues_to_use;
> + u8 max_chan = max(rx_channels_count, tx_channels_count);
> u8 chan;
>
> - for (chan = 0; chan < rx_channels_count; chan++)
> - stmmac_stop_rx_dma(priv, chan);
> -
> - for (chan = 0; chan < tx_channels_count; chan++)
> - stmmac_stop_tx_dma(priv, chan);
> + for (chan = 0; chan < max_chan; chan++) {
> + if (chan < rx_channels_count)
> + stmmac_stop_rx_dma(priv, chan);
> + if (chan < tx_channels_count)
> + stmmac_stop_tx_dma(priv, chan);
> + stmmac_deinit_chan(priv, priv->ioaddr, chan);
> + }
It is a personal preference, but i would keep the code simple, stupid,
KISS.
Keep the two loops as they are. And add a third loop calling
stmmac_deinit_chan(). That then mirrors the code in
stmmac_init_dma_engine() which also has three loops.
I would also rename max_chan to dma_csr_ch so it has the same name as
in stmmac_init_dma_engine(). As i said, stmmac has pretty bad naming,
mirror functions are not obvious, but when adding new code, we should
try to do better.
Andrew
^ permalink raw reply
* [PATCH net-next] selftests/xsk: decouple xskxceiver and xdp apps from test_progs objects
From: Tushar Vyavahare @ 2026-07-18 13:44 UTC (permalink / raw)
To: netdev, magnus.karlsson, maciej.fijalkowski, stfomichev,
kernelxing, davem, kuba, pabeni, ast, daniel, tirthendu.sarkar,
tushar.vyavahare
Cc: bpf
Build xskxceiver, xdp_hw_metadata, and xdp_features from explicit source
lists instead of reusing helper objects produced by test_progs rules.
Reusing shared objects such as network_helpers.o and xsk.o can pull in
test_progs-only dependency chains and trigger unrelated libarena builds
when invoking a single target.
Keep these standalone binaries self-contained so each target builds only
its own required sources and BPF skeleton dependencies.
Signed-off-by: Tushar Vyavahare <tushar.vyavahare@intel.com>
---
tools/testing/selftests/bpf/Makefile | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index b642ee489ea6..a6f0ed10ccb4 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -934,17 +934,27 @@ $(OUTPUT)/test_verifier: test_verifier.c verifier/tests.h $(BPFOBJ) | $(OUTPUT)
$(call msg,BINARY,,$@)
$(Q)$(CC) $(CFLAGS) $(filter %.a %.o %.c,$^) $(LDLIBS) -o $@
-# Include find_bit.c to compile xskxceiver.
-EXTRA_SRC := $(TOOLSDIR)/lib/find_bit.c prog_tests/test_xsk.c prog_tests/test_xsk.h
-$(OUTPUT)/xskxceiver: $(EXTRA_SRC) xskxceiver.c xskxceiver.h $(OUTPUT)/network_helpers.o $(OUTPUT)/xsk.o $(OUTPUT)/xsk_xdp_progs.skel.h $(BPFOBJ) | $(OUTPUT)
+# Keep xskxceiver independent from test_progs object dependencies.
+XSKXCEIVER_SRC := xskxceiver.c xsk.c network_helpers.c \
+ $(TOOLSDIR)/lib/find_bit.c prog_tests/test_xsk.c
+$(OUTPUT)/xskxceiver: $(XSKXCEIVER_SRC) xskxceiver.h xsk.h network_helpers.h \
+ prog_tests/test_xsk.h test_progs.h bpf_util.h \
+ $(OUTPUT)/xsk_xdp_progs.skel.h $(BPFOBJ) | $(OUTPUT)
$(call msg,BINARY,,$@)
$(Q)$(CC) $(CFLAGS) $(filter %.a %.o %.c,$^) $(LDLIBS) -o $@
-$(OUTPUT)/xdp_hw_metadata: xdp_hw_metadata.c $(OUTPUT)/network_helpers.o $(OUTPUT)/xsk.o $(OUTPUT)/xdp_hw_metadata.skel.h | $(OUTPUT)
+XDP_HW_METADATA_SRC := xdp_hw_metadata.c xsk.c network_helpers.c \
+ $(TOOLSDIR)/lib/find_bit.c
+$(OUTPUT)/xdp_hw_metadata: $(XDP_HW_METADATA_SRC) xdp_metadata.h \
+ xsk.h network_helpers.h test_progs.h bpf_util.h \
+ $(OUTPUT)/xdp_hw_metadata.skel.h $(BPFOBJ) | $(OUTPUT)
$(call msg,BINARY,,$@)
$(Q)$(CC) $(CFLAGS) $(filter %.a %.o %.c,$^) $(LDLIBS) -o $@
-$(OUTPUT)/xdp_features: xdp_features.c $(OUTPUT)/network_helpers.o $(OUTPUT)/xdp_features.skel.h | $(OUTPUT)
+XDP_FEATURES_SRC := xdp_features.c network_helpers.c
+$(OUTPUT)/xdp_features: $(XDP_FEATURES_SRC) xdp_features.h network_helpers.h \
+ test_progs.h bpf_util.h $(OUTPUT)/xdp_features.skel.h \
+ $(BPFOBJ) | $(OUTPUT)
$(call msg,BINARY,,$@)
$(Q)$(CC) $(CFLAGS) $(filter %.a %.o %.c,$^) $(LDLIBS) -o $@
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox