The abstraction is used by
https://lore.kernel.org/rust-for-linux/20260724-synology_microp_initial-v18-0-fb2f49f10e77@posteo.de/
.

The following changes were made:
* add basic led classdev abstractions to register and unregister leds

* add basic led classdev abstractions to register and unregister
  multicolor leds

Changes since v24:
* remove `LedOps::Bus` (Gary)
* support type-erased `Device` and `MultiColorDevice` types (Gary)
* use `Device` and `MultiColorDevice` as arbitrary self types in
  callbacks. Remove separate `classdev` argument (Gary)
* remove unnecessary imports in doc example

Changes since v23:
* add separate patch for MAINTAINERS file update

Changes since v22:
* readded CStrExt import, because it is imported with `as _` in prelude.
  A `# CONFIG_RUST is not set` sneaked into my .config while
  development, so the compile error was unnoticed.

Changes since v21:
* use 'init for lifetime that is only alive during initialization
* remove unnecessary CStrExt import

Changes since v20:
* resolve Sashiko regressions:
  * fix typo
  * fix fwnode refcount decremented too early

Changes since v19:
* rebase on v7.2-rc1:
  * Add `max_intensity` to `MultiColorSubLed`
* use safer `KBox::pin_slice` instead of `KVec`
  (len might not equal capacity)
* explicitly call `FwNode::dec_ref` instead of dropping a reconstructed
  `ARef<FwNode>`.
* remove direct access to `intensity` and `brightness` fields,
  which may get mutated concurrently by the C side
* fix safety comments pointing to functions from previous revisions

Changes since v18:
* add inlines
* fix invalid documentation
* improve led color duplicate checking

Changes since v17:
* use lifetimes instead of Devres

Changes since v16:
* use for loops for duplicate checking

Changes since v15:
* fix issues reported by Sashiko bot:
  * fix returning error not possible on `brightness_get` callback

Changes since v14:
* fix issues reported by Sashiko bot:
  * add missing inlines
  * add missing Sync trait bound
  * fix vertical import layout for public export of private types
  * fix potential memory leak, if a multicolor led device with over
    `u32::MAX` subleds is registered
* remove default_trigger option
* fix missing CAST doc

Changes since v13:
* rebased onto v7.1-rc1

Changes since v12:
* add `led::DeviceBuilder::name()` and `DeviceBuilderState'
* add `led::Color::as_c_str`

Changes since v11:
* use `led::DeviceBuilder` instead of `led::InitData`
* use static_assert instead of const { assert!(...) }
* restructured patches to avoid moving `led::Device` from
  rust/kernel/led.rs to rust/kernel/led/normal.rs in the 2. patch

Changes since v10:
* allow in-place initialization of `LedOps`
* run rustfmt for code inside `try_pin_init!`

Changes since v9:
* add missing periods in documentation
* duplicate `led::Device` and `led::Adapter` instead of using a complex
  trait
* fix imports not using prelude
* adapt to CStr change
* documented `led::Color::Multi` and `led::Color::Rgb`

Changes since v8:
* accept `Option<ARef<Fwnode>>` in `led::InitData::fwnode()`
* make functions in `MultiColorSubLed` const
* drop the "rust: Add trait to convert a device reference to a bus
  device reference" patch, as it has been picked into driver-core

Changes since v7:
* adjusted import style
* added classdev parameter to callback functions in `LedOps`
* implement `led::Color`
* extend `led::InitData` with
  - initial_brightness
  - default_trigger
  - default_color
* split generic and normal led classdev abstractions up (see patch 3/4)
* add multicolor led class device abstractions (see patch 4/4)
* added MAINTAINERS entry

Changes since v6:
* fixed typos
* improved documentation

Changes since v5:
* rename `IntoBusDevice` trait into `AsBusDevice`
* fix documentation about `LedOps::BLOCKING`
* removed dependency on i2c bindings
* added `AsBusDevice` implementation for `platform::Device`
* removed `device::Device` fallback implementation
* document that `AsBusDevice` must not be used by drivers and is
  intended for bus and class device abstractions only.

Changes since v4:
* add abstraction to convert a device reference to a bus device
  reference
* require the bus device as parent device and provide it in class device
  callbacks
* remove Pin<Vec<_>> abstraction (as not relevant for the led
  abstractions)
* fixed formatting in `led::Device::new`
* fixed `LedOps::BLOCKING` did the inverse effect

Changes since v3:
* fixed kunit tests failing because of example in documentation

Changes since v2:
* return `Devres` on `led::Device` creation
* replace KBox<T> with T in struct definition
* increment and decrement reference-count of fwnode
* make a device parent mandatory for led classdev creation
* rename `led::Handler` to `led::LedOps`
* add optional `brightness_get` function to `led::LedOps`
* use `#[vtable]` instead of `const BLINK: bool`
* use `Opaque::cast_from` instead of casting a pointer
* improve documentation
* improve support for older rust versions
* use `&Device<Bound>` for parent

Changes since v1:
* fixed typos noticed by Onur Özkan

Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
Markus Probst (4):
      rust: leds: add basic led classdev abstractions
      rust: leds: add Mode trait
      rust: leds: add multicolor classdev abstractions
      MAINTAINERS: rust: leds: Add rust abstraction entry

 MAINTAINERS                     |   8 +
 rust/bindings/bindings_helper.h |   1 +
 rust/kernel/led.rs              | 312 ++++++++++++++++++++++++++++
 rust/kernel/led/multicolor.rs   | 445 ++++++++++++++++++++++++++++++++++++++++
 rust/kernel/led/normal.rs       | 230 +++++++++++++++++++++
 rust/kernel/lib.rs              |   1 +
 6 files changed, 997 insertions(+)
---
base-commit: e5e04726cdd043e309677071ab1b65a4b18f422b
change-id: 20251114-rust_leds-a959f7c2f7f9

@Lee, @Pavel:

Hi,

This message has already been posted once [1] and no reply has been
sent. So I added your names to the subject line, so this message will
hopefully make a difference.

--- The contents of the original message:

Regarding the leds rust abstraction patch series.

Lee already mentioned he will take Rust patches into his tree if
"quality Rust-specific Reviewed-by" trailers are present [2].
Will this also apply for any subsequent patches (e.g. bug fixes)?

Secondly, there hasn't been a comment on me taking the maintainer role
for the Rust abstraction yet. If thats fine with you, I kindly ask you
to ACK the patch adding the MAINTAINERS file entry [3].

I was told there have been cases in the past of maintainers leaving the
kernel directly after code has been merged. To take away any fears that
might exist, I can assure you I will take care of the Rust code.

If there is a patch with breaking API changes on the C side, simply add
me to Cc and I will fix the Rust side.

The missing ACK on the patch adding the MAINTAINERS file entry [3] and
the missing Reviewed-By Rust trailers should be the only blockers of
this patch series.

Thanks
- Markus Probst

[1]
https://lore.kernel.org/rust-for-linux/6c57e08a5f4aa9096711d14d82ece19fb68c893f.camel@posteo.de/

[2]
https://lore.kernel.org/linux-leds/20251110134058.GC1949330@google.com/

[3]
https://lore.kernel.org/linux-leds/20260903-rust_leds-v24-4-8d9e4c04db69@posteo.de/

On Tue, 22 Sep 2026, Markus Probst wrote:

> @Lee, @Pavel:
> 
> Hi,
> 
> This message has already been posted once [1] and no reply has been
> sent. So I added your names to the subject line, so this message will
> hopefully make a difference.
> 
> --- The contents of the original message:
> 
> Regarding the leds rust abstraction patch series.
> 
> Lee already mentioned he will take Rust patches into his tree if
> "quality Rust-specific Reviewed-by" trailers are present [2].
> Will this also apply for any subsequent patches (e.g. bug fixes)?

I'd be happy to either take them in or let you set-up your own
maintainer tree.

> Secondly, there hasn't been a comment on me taking the maintainer role
> for the Rust abstraction yet. If thats fine with you, I kindly ask you
> to ACK the patch adding the MAINTAINERS file entry [3].

Fine by me.

> I was told there have been cases in the past of maintainers leaving the
> kernel directly after code has been merged. To take away any fears that
> might exist, I can assure you I will take care of the Rust code.
> 
> If there is a patch with breaking API changes on the C side, simply add
> me to Cc and I will fix the Rust side.
> 
> The missing ACK on the patch adding the MAINTAINERS file entry [3] and
> the missing Reviewed-By Rust trailers should be the only blockers of
> this patch series.

Those are quite large blockers, but yes.

> Thanks
> - Markus Probst
> 
> [1]
> https://lore.kernel.org/rust-for-linux/6c57e08a5f4aa9096711d14d82ece19fb68c893f.camel@posteo.de/
> 
> [2]
> https://lore.kernel.org/linux-leds/20251110134058.GC1949330@google.com/
> 
> [3]
> https://lore.kernel.org/linux-leds/20260903-rust_leds-v24-4-8d9e4c04db69@posteo.de/



-- 
Lee Jones