[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <DDHGUQ9B4J2K.X1VXMMU6O5O4@kernel.org>
Date: Mon, 13 Oct 2025 22:11:14 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Alice Ryhl" <aliceryhl@...gle.com>
Cc: "Markus Probst" <markus.probst@...teo.de>, "Miguel Ojeda"
<ojeda@...nel.org>, "Alex Gaynor" <alex.gaynor@...il.com>, "Lee Jones"
<lee@...nel.org>, "Pavel Machek" <pavel@...nel.org>, "Lorenzo Stoakes"
<lorenzo.stoakes@...cle.com>, "Vlastimil Babka" <vbabka@...e.cz>, "Liam R.
Howlett" <Liam.Howlett@...cle.com>, "Uladzislau Rezki" <urezki@...il.com>,
"Boqun Feng" <boqun.feng@...il.com>, "Gary Guo" <gary@...yguo.net>,
<bjorn3_gh@...tonmail.com>, "Benno Lossin" <lossin@...nel.org>, "Andreas
Hindborg" <a.hindborg@...nel.org>, "Trevor Gross" <tmgross@...ch.edu>,
<rust-for-linux@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-leds@...r.kernel.org>
Subject: Re: [PATCH v4 2/2] rust: leds: add basic led classdev abstractions
On Mon Oct 13, 2025 at 8:34 PM CEST, Alice Ryhl wrote:
> On Sun, Oct 12, 2025 at 02:52:39PM +0000, Markus Probst wrote:
>> Implement the core abstractions needed for led class devices, including:
>>
>> * `led::LedOps` - the trait for handling leds, including
>> `brightness_set`, `brightness_get` and `blink_set`
>>
>> * `led::InitData` - data set for the led class device
>>
>> * `led::Device` - a safe wrapper around `led_classdev`
>>
>> Signed-off-by: Markus Probst <markus.probst@...teo.de>
>
>> +pub trait LedOps: Send + 'static + Sized {
>> + /// If set true, [`LedOps::brightness_set`] and [`LedOps::blink_set`] must not sleep
>> + /// and perform the operation immediately.
>> + const BLOCKING: bool;
>> + /// The max brightness level
>> + const MAX_BRIGHTNESS: u32;
>> +
>> + /// Sets the brightness level.
>> + ///
>> + /// See also [`LedOps::BLOCKING`]
>> + fn brightness_set(&self, brightness: u32) -> Result<()>;
>> +
>> + /// Gets the current brightness level.
>> + fn brightness_get(&self) -> u32 {
>> + build_error!(VTABLE_DEFAULT_ERROR)
>> + }
>> +
>> + /// Activates hardware accelerated blinking.
>> + ///
>> + /// delays are in milliseconds. If both are zero, a sensible default should be chosen.
>> + /// The caller should adjust the timings in that case and if it can't match the values
>> + /// specified exactly. Setting the brightness to 0 will disable the hardware accelerated
>> + /// blinking.
>> + ///
>> + /// See also [`LedOps::BLOCKING`]
>> + fn blink_set(&self, _delay_on: &mut usize, _delay_off: &mut usize) -> Result<()> {
>> + build_error!(VTABLE_DEFAULT_ERROR)
>> + }
>
> These functions should probably take a &Device<Bound> argument so that
> they can use methods that require a bound device (such as IO).
Indeed!
@Markus: Note that this guarantee is given by the LED device registration being
lifetime controlled by devres, while led_classdev_unregister() is synchronized
against those callbacks.
For the latter, please double check that this is actually the case -- I'm not
familiar with the LED subsystem, I'm reviewing from driver-core perspective. But
from a quick look it should be the case. :)
Powered by blists - more mailing lists