mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Markus Probst <markus.probst@posteo.de>
To: Alice Ryhl <aliceryhl@google.com>
Cc: Danilo Krummrich <dakr@kernel.org>,
	Miguel Ojeda <ojeda@kernel.org>,
	 Alex Gaynor <alex.gaynor@gmail.com>, Lee Jones <lee@kernel.org>,
	Pavel Machek <pavel@kernel.org>,
	 Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	"Liam R. Howlett"	 <Liam.Howlett@oracle.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Boqun Feng	 <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
	bjorn3_gh@protonmail.com,  Benno Lossin <lossin@kernel.org>,
	Andreas Hindborg <a.hindborg@kernel.org>,
	Trevor Gross <tmgross@umich.edu>,
	 rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux-leds@vger.kernel.org
Subject: Re: [PATCH v4 2/2] rust: leds: add basic led classdev abstractions
Date: Wed, 15 Oct 2025 13:44:45 +0000	[thread overview]
Message-ID: <7de58fd25b52dd5195c8ac06ed4df5a1e60e5070.camel@posteo.de> (raw)
In-Reply-To: <aO1GM4WXs37Zpm0G@google.com>

On Mon, 2025-10-13 at 18:34 +0000, 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@posteo.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).
How about instead something like

mod device {

  unsafe trait Container<Ctx: DeviceContext>: AsRef<Device<Ctx>> {
    const Offset: usize;

    unsafe fn from_device(dev: &Device<Ctx>) -> &Self {
       <implementation here>
    }
  }

  unsafe impl Device<Ctx> for Container<Ctx> {
    const Offset: usize = 0;
  }

}

And instead of passing &Device<Bound> to the functions, we should add a
type parameter to LedOps, e.g.:

trait LedOps<T: device::Container<device::Bound>> {

  ...

  fn brightness_set(&self, dev: &T, brightness: u32) -> Result<()>;

  ...

}

impl<T: LedOps<E>, E: device::Container<device::Bound>> Device<T> {

  pub fn new<'a>(
        parent: &'a E,
        init_data: InitData<'a>,
        ops: T,
    ) -> impl PinInit<Devres<Self>, Error> + 'a {
     ...
  }

  ...

}

In the example of i2c (or any other container for `struct device`), we
implement the device::Container trait:

mod i2c {

  unsafe impl device::Container for I2cClient {
    const Offset: usize = offset_of!(bindings::i2c_client, dev);
  }

}
This allows the LedOps function to use any functions from the I2cClient
or any other device container which may be used (removing the need to
store it inside the LedOps implementations struct). It still allows
Device<Bound> to be used, as it also would implement device::Container.

Thanks
- Markus Probst

> 
> > +impl<T: LedOps> Device<T> {
> > +    /// Registers a new led classdev.
> > +    ///
> > +    /// The [`Device`] will be unregistered on drop.
> > +    pub fn new<'a>(
> > +        parent: &'a device::Device<Bound>,
> > +        init_data: InitData<'a>,
> > +        ops: T,
> > +    ) -> impl PinInit<Devres<Self>, Error> + 'a {
> > +        Devres::new(
> > +            parent,
> > +            try_pin_init!(Self {
> > +                ops,
> > +                classdev <- Opaque::try_ffi_init(|ptr: *mut
> > bindings::led_classdev| {
> > +                    // SAFETY: `try_ffi_init` guarantees that
> > `ptr` is valid for write.
> > +                    // `led_classdev` gets fully initialized in-
> > place by
> > +                    // `led_classdev_register_ext` including
> > `mutex` and `list_head`.
> > +                    unsafe { ptr.write(bindings::led_classdev {
> > +                        max_brightness: T::MAX_BRIGHTNESS,
> > +                        brightness_set: T::BLOCKING
> > +                           
> > .then_some(Adapter::<T>::brightness_set_callback),
> > +                        brightness_set_blocking: (!T::BLOCKING)
> > +                           
> > .then_some(Adapter::<T>::brightness_set_blocking_callback),
> > +                        brightness_get: T::HAS_BRIGHTNESS_GET
> > +                           
> > .then_some(Adapter::<T>::brightness_get_callback),
> > +                        blink_set: T::HAS_BLINK_SET
> > +                           
> > .then_some(Adapter::<T>::blink_set_callback),
> > +                        .. bindings::led_classdev::default()
> > +                    }) };
> 
> This doesn't look like something rustfmt would output? Could you run
> rustfmt if you haven't already. If it doesn't do anything, then
> please
> format it outside of the macro and move it back in.
> 
> Alice

  parent reply	other threads:[~2025-10-15 13:44 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-12 14:52 [PATCH v4 0/2] rust: leds: add " Markus Probst
2025-10-12 14:52 ` [PATCH v4 1/2] rust: add basic Pin<Vec<T, A>> abstractions Markus Probst
2025-10-12 16:26   ` Benno Lossin
2025-10-12 16:57     ` Markus Probst
2025-10-12 21:31       ` Benno Lossin
2025-10-12 22:11         ` Markus Probst
2025-10-13  8:03           ` Benno Lossin
2025-10-13  9:22             ` Alice Ryhl
2025-10-13  9:39               ` Benno Lossin
2025-10-13 13:43             ` Markus Probst
2025-10-13 14:47               ` Benno Lossin
2025-10-14 14:15                 ` Markus Probst
2025-10-12 14:52 ` [PATCH v4 2/2] rust: leds: add basic led classdev abstractions Markus Probst
2025-10-13 18:34   ` Alice Ryhl
2025-10-13 20:11     ` Danilo Krummrich
2025-10-14 14:46       ` Markus Probst
2025-10-15 13:44     ` Markus Probst [this message]
2025-10-15 14:52       ` Danilo Krummrich
2025-10-15 15:02         ` Markus Probst
2025-10-15 17:27           ` Danilo Krummrich
2025-10-12 16:27 ` [PATCH v4 0/2] rust: leds: add " Benno Lossin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7de58fd25b52dd5195c8ac06ed4df5a1e60e5070.camel@posteo.de \
    --to=markus.probst@posteo.de \
    --cc=Liam.Howlett@oracle.com \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=gary@garyguo.net \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=pavel@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=urezki@gmail.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®