linux-toradex.git/drivers/leds, branch master Linux kernel for Apalis and Colibri modules Merge tag 'leds-next-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds 2026-10-26T18:55:14+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-10-26T18:55:14+00:00 5b93dc1c0c61fd0fe575cb473e9e25f929fda509 Pull LED updates from Lee Jones: "New Support & Features: - Core: Add `led_trigger_notify_hw_control_changed()` to allow drivers to notify the core of autonomous hardware control transitions - Core: Add the `hw_offloaded()` trigger callback and `trigger_may_offload_to_hw` sysfs attribute to expose hardware-offloaded triggers - Netdev Trigger: Implement the `hw_offloaded()` callback to report hardware control state to the LED core - Analog Devices LTC3208: Add support for the LTC3208 7-channel multi-display I2C LED driver - ChromeOS EC: Implement the `hw_offloaded()` callback for the `chromeos-auto` trigger - CZ.NIC Turris Omnia: Implement the `hw_offloaded()` callback and declare `omnia-mcu` as a hardware control trigger - STMicroelectronics ST1202: Add hardware-accelerated blink support via `blink_set()` Improvements & Fixes: - Class: Always hold the `led_access` mutex in `brightness_show()` to avoid exposing transient registration states - Class: Deactivate active hardware control triggers when writing to the `brightness` sysfs attribute - Core: Enforce strict validation in `led_trigger_is_hw_controlled()` and warn on legacy fallback paths - Flash Class: Initialize the fault variable in `flash_fault_show()` to prevent undefined behavior when callbacks perform bitwise ORs - Kinetic KTD2692: Pass the driver context directly to `regulator_disable_action()` to prevent a NULL pointer dereference during error unwinding - Maxim MAX77705: Use `fwnode_for_each_child_node_scoped()` in `max77705_add_led()` to prevent child node reference leaks on error paths - NXP PCA9532: Check the return value of `i2c_smbus_read_byte_data()` in `pca9532_getled()` to avoid integer underflow on read errors - Qualcomm WLED: Fix a NULL pointer dereference in `wled_remove()` by setting platform driver data in `wled_probe()` - Qualcomm WLED: Fix the WLED3 brightness register stride to prevent consecutive string writes from overlapping - Qualcomm WLED: Read back the hardware-programmed brightness at probe, expose it via `get_brightness()`, and prevent unbalanced OVP IRQ enabling - STMicroelectronics ST1202: Clear unused PWM pattern slots in `pattern_set()` and `blink_set()` to prevent unintended output when sharing the global sequencer - STMicroelectronics ST1202: Program and cap the channel current according to `max_brightness` across brightness, blink, and hardware pattern modes, and scale pattern brightness to the 12-bit PWM range - STMicroelectronics ST1202: Retain a reference to each child LED firmware node for the lifetime of the device - STMicroelectronics ST1202: Use only the blocking `brightness_set_blocking()` callback to avoid sleeping in atomic context during I2C transfers - TI LM3692x: Check the final register write in `lm3692x_leds_enable()` to prevent regulator/GPIO leaks and an inconsistent enabled state - TI LP8860: Fix a `device_node` reference leak in `lp8860_probe()` using `__free(device_node)` Cleanups & Refactoring: - Core: Move `led_trigger_is_hw_controlled()` and `led_trigger_group` from `led-class.c` into `led-triggers.c` - Core: Replace conditional `set_bit()`/`clear_bit()` patterns with `assign_bit()` and `__assign_bit()` - Flash Class: Simplify `flash_fault_show()` using `sysfs_emit_at()` and omit the trailing space - Maintainers: Add Griffin Kroah-Hartman as an LED subsystem reviewer - Intel SS4200: Fix a spelling typo in a comment - ISSI IS31FL32xx: Convert DT-specific parsing helpers to generic device and fwnode property APIs - NXP PCA955x: Drop redundant intermediate platform data and allocate the LED array using a flexible array member - Qualcomm LPG: Convert LED and channel parsing to fwnode APIs and avoid leaving `default_trigger` uninitialized - Skyworks AAT1290: Use `ARRAY_SIZE()` when allocating `mm_current_scale` to match the target pointer type for type-aware allocators - STMicroelectronics ST1202: Introduce a `st1202_iled_max()` helper to unify channel current ceiling calculations - STMicroelectronics ST1202: Standardize variable and macro naming, fix helper spelling, and use `u8` consistently instead of `uint8_t` - Syscon: Convert from OF-specific property helpers to the generic device property and fwnode APIs Device Tree Binding Updates: - Core: Allow PHY RX triggers (`phy[0-9]+rx`) in `linux,default-trigger` - Core: Standardize example indentation across multiple LED and backlight binding schemas - Analog Devices LTC3208: Document the LTC3208 multi-display LED driver - LaCie netxbig: Convert LED bindings to DT schema - Motorola CPCAP: Convert LED bindings to DT schemaLEDs for v7.4" * tag 'leds-next-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (49 commits) dt-bindings: leds: lacie,netxbig-leds: Convert to DT schema leds: pca955x: Drop platform data and allocate LEDs with the device dt-bindings: leds: Use consistent indentation in the example backlight: qcom-wled: Read back the programmed brightness at probe backlight: qcom-wled: Fix unbalanced OVP IRQ enable at probe backlight: qcom-wled: Fix WLED3 brightness register stride backlight: qcom-wled: Fix NULL pointer dereference in wled_remove() dt-bindings: leds: Allow PHY RX triggers MAINTAINERS: Add myself as a LED SUBSYSTEM reviewer leds: trigger: Add led_trigger_notify_hw_control_changed() interface leds: trigger: Enforce strict checks in led_trigger_is_hw_controlled() leds: trigger: netdev: Implement hw_offloaded() callback leds: turris-omnia: Implement hw_offloaded() trigger callback and declare hw_control_trigger leds: cros_ec: Implement hw_offloaded() trigger callback leds: trigger: Add hw_offloaded() callback and provide trigger_may_offload_to_hw attribute leds: trigger: Move led_trigger_group to the right place leds: class: Remove hardware control trigger when writing brightness leds: trigger: Move led_trigger_is_hw_controlled() to the right place leds: class: Always protect brightness_show() with led_access dt-bindings: leds: leds-cpcap: Convert to DT schema ... 
Pull LED updates from Lee Jones:
 "New Support & Features:
   - Core: Add `led_trigger_notify_hw_control_changed()` to allow
     drivers to notify the core of autonomous hardware control
     transitions
   - Core: Add the `hw_offloaded()` trigger callback and
     `trigger_may_offload_to_hw` sysfs attribute to expose
     hardware-offloaded triggers
   - Netdev Trigger: Implement the `hw_offloaded()` callback to report
     hardware control state to the LED core
   - Analog Devices LTC3208: Add support for the LTC3208 7-channel
     multi-display I2C LED driver
   - ChromeOS EC: Implement the `hw_offloaded()` callback for the
     `chromeos-auto` trigger
   - CZ.NIC Turris Omnia: Implement the `hw_offloaded()` callback and
     declare `omnia-mcu` as a hardware control trigger
   - STMicroelectronics ST1202: Add hardware-accelerated blink support
     via `blink_set()`

  Improvements & Fixes:
   - Class: Always hold the `led_access` mutex in `brightness_show()` to
     avoid exposing transient registration states
   - Class: Deactivate active hardware control triggers when writing to
     the `brightness` sysfs attribute
   - Core: Enforce strict validation in `led_trigger_is_hw_controlled()`
     and warn on legacy fallback paths
   - Flash Class: Initialize the fault variable in `flash_fault_show()`
     to prevent undefined behavior when callbacks perform bitwise ORs
   - Kinetic KTD2692: Pass the driver context directly to
     `regulator_disable_action()` to prevent a NULL pointer dereference
     during error unwinding
   - Maxim MAX77705: Use `fwnode_for_each_child_node_scoped()` in
     `max77705_add_led()` to prevent child node reference leaks on error
     paths
   - NXP PCA9532: Check the return value of `i2c_smbus_read_byte_data()`
     in `pca9532_getled()` to avoid integer underflow on read errors
   - Qualcomm WLED: Fix a NULL pointer dereference in `wled_remove()` by
     setting platform driver data in `wled_probe()`
   - Qualcomm WLED: Fix the WLED3 brightness register stride to prevent
     consecutive string writes from overlapping
   - Qualcomm WLED: Read back the hardware-programmed brightness at
     probe, expose it via `get_brightness()`, and prevent unbalanced OVP
     IRQ enabling
   - STMicroelectronics ST1202: Clear unused PWM pattern slots in
     `pattern_set()` and `blink_set()` to prevent unintended output when
     sharing the global sequencer
   - STMicroelectronics ST1202: Program and cap the channel current
     according to `max_brightness` across brightness, blink, and
     hardware pattern modes, and scale pattern brightness to the 12-bit
     PWM range
   - STMicroelectronics ST1202: Retain a reference to each child LED
     firmware node for the lifetime of the device
   - STMicroelectronics ST1202: Use only the blocking
     `brightness_set_blocking()` callback to avoid sleeping in atomic
     context during I2C transfers
   - TI LM3692x: Check the final register write in
     `lm3692x_leds_enable()` to prevent regulator/GPIO leaks and an
     inconsistent enabled state
   - TI LP8860: Fix a `device_node` reference leak in `lp8860_probe()`
     using `__free(device_node)`

  Cleanups & Refactoring:
   - Core: Move `led_trigger_is_hw_controlled()` and `led_trigger_group`
     from `led-class.c` into `led-triggers.c`
   - Core: Replace conditional `set_bit()`/`clear_bit()` patterns with
     `assign_bit()` and `__assign_bit()`
   - Flash Class: Simplify `flash_fault_show()` using `sysfs_emit_at()`
     and omit the trailing space
   - Maintainers: Add Griffin Kroah-Hartman as an LED subsystem reviewer
   - Intel SS4200: Fix a spelling typo in a comment
   - ISSI IS31FL32xx: Convert DT-specific parsing helpers to generic
     device and fwnode property APIs
   - NXP PCA955x: Drop redundant intermediate platform data and allocate
     the LED array using a flexible array member
   - Qualcomm LPG: Convert LED and channel parsing to fwnode APIs and
     avoid leaving `default_trigger` uninitialized
   - Skyworks AAT1290: Use `ARRAY_SIZE()` when allocating
     `mm_current_scale` to match the target pointer type for type-aware
     allocators
   - STMicroelectronics ST1202: Introduce a `st1202_iled_max()` helper
     to unify channel current ceiling calculations
   - STMicroelectronics ST1202: Standardize variable and macro naming,
     fix helper spelling, and use `u8` consistently instead of `uint8_t`
   - Syscon: Convert from OF-specific property helpers to the generic
     device property and fwnode APIs

  Device Tree Binding Updates:
   - Core: Allow PHY RX triggers (`phy[0-9]+rx`) in
     `linux,default-trigger`
   - Core: Standardize example indentation across multiple LED and
     backlight binding schemas
   - Analog Devices LTC3208: Document the LTC3208 multi-display LED
     driver
   - LaCie netxbig: Convert LED bindings to DT schema
   - Motorola CPCAP: Convert LED bindings to DT schemaLEDs for v7.4"

* tag 'leds-next-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (49 commits)
  dt-bindings: leds: lacie,netxbig-leds: Convert to DT schema
  leds: pca955x: Drop platform data and allocate LEDs with the device
  dt-bindings: leds: Use consistent indentation in the example
  backlight: qcom-wled: Read back the programmed brightness at probe
  backlight: qcom-wled: Fix unbalanced OVP IRQ enable at probe
  backlight: qcom-wled: Fix WLED3 brightness register stride
  backlight: qcom-wled: Fix NULL pointer dereference in wled_remove()
  dt-bindings: leds: Allow PHY RX triggers
  MAINTAINERS: Add myself as a LED SUBSYSTEM reviewer
  leds: trigger: Add led_trigger_notify_hw_control_changed() interface
  leds: trigger: Enforce strict checks in led_trigger_is_hw_controlled()
  leds: trigger: netdev: Implement hw_offloaded() callback
  leds: turris-omnia: Implement hw_offloaded() trigger callback and declare hw_control_trigger
  leds: cros_ec: Implement hw_offloaded() trigger callback
  leds: trigger: Add hw_offloaded() callback and provide trigger_may_offload_to_hw attribute
  leds: trigger: Move led_trigger_group to the right place
  leds: class: Remove hardware control trigger when writing brightness
  leds: trigger: Move led_trigger_is_hw_controlled() to the right place
  leds: class: Always protect brightness_show() with led_access
  dt-bindings: leds: leds-cpcap: Convert to DT schema
  ...
leds: pca955x: Drop platform data and allocate LEDs with the device 2026-10-15T15:52:15+00:00 Rosen Penev rosenp@gmail.com 2026-10-05T20:09:06+00:00 7260db6364a2999f2f85bae8afb6b4d22e41fc8a struct pca955x_platform_data has been private to this driver since commit ed1f4b9676a8 ("leds: pca955x: add device tree support"), so nothing can pass it in through dev_get_platdata() and it only serves as an intermediate copy of the per-LED type, default state and fwnode. That copy is a full array of struct pca955x_led, the same runtime structure that struct pca955x already holds, so the data is stored twice. Remove the platform data and parse the child firmware nodes directly into pca955x->leds[]. Make leds[] a flexible array member so it is allocated together with struct pca955x. This removes three allocations and the num_leds sanity check, which could no longer fail. struct pca955x_led moves above struct pca955x, as a flexible array member needs the complete element type. Assisted-by: LLM Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20261005200906.188636-1-rosenp@gmail.com Signed-off-by: Lee Jones <lee@kernel.org> 
struct pca955x_platform_data has been private to this driver since
commit ed1f4b9676a8 ("leds: pca955x: add device tree support"), so
nothing can pass it in through dev_get_platdata() and it only serves
as an intermediate copy of the per-LED type, default state and fwnode.
That copy is a full array of struct pca955x_led, the same runtime
structure that struct pca955x already holds, so the data is stored
twice.

Remove the platform data and parse the child firmware nodes directly
into pca955x->leds[]. Make leds[] a flexible array member so it is
allocated together with struct pca955x. This removes three
allocations and the num_leds sanity check, which could no longer
fail.

struct pca955x_led moves above struct pca955x, as a flexible array
member needs the complete element type.

Assisted-by: LLM
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20261005200906.188636-1-rosenp@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
leds: trigger: Add led_trigger_notify_hw_control_changed() interface 2026-09-24T12:17:32+00:00 Rong Zhang i@rong.moe 2026-09-20T19:40:24+00:00 05b4738b0078f7d6f154f68068a11c8a0635e9df 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, the config LEDS_TRIGGERS_HW_CHANGED must be enabled, and the LED driver must set the LED_TRIG_HW_CHANGED flag for the classdev. By default, the config is enabled when LEDS_BRIGHTNESS_HW_CHANGED is enabled. Acked-by: Ike Panhc <ikepanhc@gmail.com> Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-10-fe3cdb6dec51@rong.moe Signed-off-by: Lee Jones <lee@kernel.org> 
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, the config LEDS_TRIGGERS_HW_CHANGED must be
enabled, and the LED driver must set the LED_TRIG_HW_CHANGED flag for
the classdev.

By default, the config is enabled when LEDS_BRIGHTNESS_HW_CHANGED is
enabled.

Acked-by: Ike Panhc <ikepanhc@gmail.com>
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-10-fe3cdb6dec51@rong.moe
Signed-off-by: Lee Jones <lee@kernel.org>
leds: trigger: Enforce strict checks in led_trigger_is_hw_controlled() 2026-09-24T12:17:32+00:00 Rong Zhang i@rong.moe 2026-09-20T19:40:23+00:00 7b9a609575615a3ba18a31a95282e756e34bd506 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 hw_offloaded() callback to indicate hardware control - Associate with the LED classdev's hw_control_trigger string The fallback path is kept, but a warning message is emitted when it reaches there. Acked-by: Ike Panhc <ikepanhc@gmail.com> Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-9-fe3cdb6dec51@rong.moe Signed-off-by: Lee Jones <lee@kernel.org> 
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 hw_offloaded() callback to indicate hardware control
- Associate with the LED classdev's hw_control_trigger string

The fallback path is kept, but a warning message is emitted when it
reaches there.

Acked-by: Ike Panhc <ikepanhc@gmail.com>
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-9-fe3cdb6dec51@rong.moe
Signed-off-by: Lee Jones <lee@kernel.org>
leds: trigger: netdev: Implement hw_offloaded() callback 2026-09-24T12:17:32+00:00 Rong Zhang i@rong.moe 2026-09-20T19:40:22+00:00 072e0e799bc6b3909afc8fd7fac750b31e37b438 "netdev" can run in hardware control according to hardware capabilities and trigger options. Implement hw_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_to_hw" attribute. The callback mimics how the existing "offloaded" attribute does, i.e., locklessly reads hw_control, as it's just a hint and don't need to be accurate. Acked-by: Ike Panhc <ikepanhc@gmail.com> Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-8-fe3cdb6dec51@rong.moe Signed-off-by: Lee Jones <lee@kernel.org> 
"netdev" can run in hardware control according to hardware capabilities
and trigger options.

Implement hw_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_to_hw"
attribute.

The callback mimics how the existing "offloaded" attribute does, i.e.,
locklessly reads hw_control, as it's just a hint and don't need to be
accurate.

Acked-by: Ike Panhc <ikepanhc@gmail.com>
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-8-fe3cdb6dec51@rong.moe
Signed-off-by: Lee Jones <lee@kernel.org>
leds: turris-omnia: Implement hw_offloaded() trigger callback and declare hw_control_trigger 2026-09-24T12:17:32+00:00 Rong Zhang i@rong.moe 2026-09-20T19:40:21+00:00 f5005c7cec7d4cff58f25442ed6dfca56e42b16d "omnia-mcu" is a private hardware control trigger which always stays in hardware control mode. Implement hw_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. Acked-by: Ike Panhc <ikepanhc@gmail.com> Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-7-fe3cdb6dec51@rong.moe Signed-off-by: Lee Jones <lee@kernel.org> 
"omnia-mcu" is a private hardware control trigger which always stays in
hardware control mode. Implement hw_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.

Acked-by: Ike Panhc <ikepanhc@gmail.com>
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-7-fe3cdb6dec51@rong.moe
Signed-off-by: Lee Jones <lee@kernel.org>
leds: cros_ec: Implement hw_offloaded() trigger callback 2026-09-24T12:17:32+00:00 Rong Zhang i@rong.moe 2026-09-20T19:40:20+00:00 b366a50d39d13f8230f959b457abcaeba1e7d121 "chromeos-auto" is a private hardware control trigger which always stays in hardware control. Implement hw_offloaded() callback with its return value to be always true to reflect this. Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Ike Panhc <ikepanhc@gmail.com> Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-6-fe3cdb6dec51@rong.moe Signed-off-by: Lee Jones <lee@kernel.org> 
"chromeos-auto" is a private hardware control trigger which always stays
in hardware control. Implement hw_offloaded() callback with its return
value to be always true to reflect this.

Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Ike Panhc <ikepanhc@gmail.com>
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-6-fe3cdb6dec51@rong.moe
Signed-off-by: Lee Jones <lee@kernel.org>
leds: trigger: Add hw_offloaded() callback and provide trigger_may_offload_to_hw attribute 2026-09-24T12:17:32+00:00 Rong Zhang i@rong.moe 2026-09-20T19:40:19+00:00 8e04e5382aa989ae9a36dc0cb3f3c90347d5607f 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 hw_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_to_hw", 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 and offloaded to hardware ("[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. IOW, userspace should parse the new attribute in the same way as /sys/class/leds/<led>/trigger. Acked-by: Ike Panhc <ikepanhc@gmail.com> Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-5-fe3cdb6dec51@rong.moe Signed-off-by: Lee Jones <lee@kernel.org> 
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 hw_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_to_hw", 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 and offloaded to hardware ("[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. IOW, userspace
should parse the new attribute in the same way as
/sys/class/leds/<led>/trigger.

Acked-by: Ike Panhc <ikepanhc@gmail.com>
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-5-fe3cdb6dec51@rong.moe
Signed-off-by: Lee Jones <lee@kernel.org>
leds: trigger: Move led_trigger_group to the right place 2026-09-24T12:17:32+00:00 Rong Zhang i@rong.moe 2026-09-20T19:40:18+00:00 43b83e7462e8e9b96e14262c0b6aa739f01c38f7 Currently led_trigger_group and its members are placed at led-class.c, but they falls into the triggers namespace and does triggers stuff. Placing them at led-class.c also requires the read and write callback to be exported and results in an extra #ifdef block. Move it into led-triggers.c, so that it becomes the only symbol to be exported for sysfs attributes. Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-4-fe3cdb6dec51@rong.moe Signed-off-by: Lee Jones <lee@kernel.org> 
Currently led_trigger_group and its members are placed at led-class.c,
but they falls into the triggers namespace and does triggers stuff.
Placing them at led-class.c also requires the read and write callback to
be exported and results in an extra #ifdef block.

Move it into led-triggers.c, so that it becomes the only symbol to be
exported for sysfs attributes.

Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-4-fe3cdb6dec51@rong.moe
Signed-off-by: Lee Jones <lee@kernel.org>
leds: class: Remove hardware control trigger when writing brightness 2026-09-24T12:17:32+00:00 Rong Zhang i@rong.moe 2026-09-20T19:40:17+00:00 96b4ddd6d2d8c645d672f1f26130685d9f40cf2f 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") Acked-by: Ike Panhc <ikepanhc@gmail.com> Signed-off-by: Rong Zhang <i@rong.moe> Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-3-fe3cdb6dec51@rong.moe Signed-off-by: Lee Jones <lee@kernel.org> 
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")
Acked-by: Ike Panhc <ikepanhc@gmail.com>
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260921-leds-trigger-hw-changed-v7-3-fe3cdb6dec51@rong.moe
Signed-off-by: Lee Jones <lee@kernel.org>