From: Alice Ryhl <aliceryhl@google.com>
To: Bruce Robertson <brucer42@gmail.com>
Cc: rust-for-linux@vger.kernel.org, linux-pm@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
Sebastian Reichel <sre@kernel.org>,
Miguel Ojeda <ojeda@kernel.org>,
Igor Korotin <igor.korotin@linux.dev>,
Gary Guo <gary@garyguo.net>,
Tamir Duberstein <tamird@kernel.org>,
Boqun Feng <boqun@kernel.org>
Subject: Re: [RFC PATCH 2/3] rust: power_supply: add power supply class abstraction
Date: Thu, 9 Jul 2026 09:04:00 +0000 [thread overview]
Message-ID: <ak9kAP1SZF8AchQT@google.com> (raw)
In-Reply-To: <20260708214738.25008-3-brucer42@gmail.com>
On Wed, Jul 08, 2026 at 09:47:37PM +0000, Bruce Robertson wrote:
> There is no Rust abstraction for the power supply class in mainline or
> rust-next. Add a minimal one:
>
> - a Driver trait carrying the supply's name, type and property list,
> plus a get_property() method;
> - a generic extern "C" trampoline the power supply core calls back
> into, recovering the driver's private data via the parent device and
> dispatching to get_property();
> - a Registration that owns the power_supply_desc and unregisters the
> supply on drop, freeing the descriptor in the correct order.
>
> Property, type and status constants are re-exported so drivers need not
> reach into the generated bindings directly.
>
> Signed-off-by: Bruce Robertson <brucer42@gmail.com>
> +impl Drop for Registration {
> + fn drop(&mut self) {
> + // SAFETY: `psy` came from a successful `power_supply_register` and has not been
> + // unregistered. `power_supply_unregister` blocks until no callback is running;
> + // `_desc` (dropped immediately after) is then no longer referenced by the core.
> + unsafe { bindings::power_supply_unregister(self.psy) };
> + }
> +}
> +
> +/// Register a power supply backed by driver `T` against `dev`.
> +pub fn register<T: Driver + 'static>(dev: &Device) -> Result<Registration> {
Should this be &Device<Bound>?
> + let mut desc = KBox::new(bindings::power_supply_desc::default(), GFP_KERNEL)?;
> + desc.name = T::NAME.as_char_ptr();
> + desc.type_ = T::TYPE;
> + desc.properties = T::PROPERTIES.as_ptr();
> + desc.num_properties = T::PROPERTIES.len();
> + desc.get_property = Some(get_property_trampoline::<T>);
> +
> + // Stable heap address; moving the KBox into `Registration` keeps this valid
> + // (moving a KBox moves the pointer, not the heap allocation).
> + let desc_ptr: *const bindings::power_supply_desc = &*desc;
> +
> + let cfg = bindings::power_supply_config {
> + drv_data: dev.as_raw().cast::<kernel::ffi::c_void>(),
> + ..Default::default()
> + };
> +
> + // SAFETY: `dev` valid; `desc_ptr` points into `desc`, kept alive in the returned
> + // `Registration` and freed only after `power_supply_unregister`; `cfg` valid for the call.
> + let psy = unsafe { bindings::power_supply_register(dev.as_raw(), desc_ptr, &cfg) };
> + let psy = from_err_ptr(psy)?;
> +
> + Ok(Registration { psy, _desc: desc })
> +}
This looks like it should be a ::new() method on Registration instead?
I would compare with existing Registration abstractions and mirror how
they do it.
Alice
next prev parent reply other threads:[~2026-07-09 9:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 21:47 [RFC PATCH 0/3] rust: power_supply class abstraction and SMB347 charger driver Bruce Robertson
2026-07-08 21:47 ` [RFC PATCH 1/3] rust: i2c: add SMBus byte transfer helpers Bruce Robertson
2026-07-11 10:34 ` Igor Korotin
2026-07-11 12:06 ` Danilo Krummrich
2026-07-08 21:47 ` [RFC PATCH 2/3] rust: power_supply: add power supply class abstraction Bruce Robertson
2026-07-09 9:04 ` Alice Ryhl [this message]
2026-07-08 21:47 ` [RFC PATCH 3/3] power: supply: add Rust SMB347 charger driver Bruce Robertson
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=ak9kAP1SZF8AchQT@google.com \
--to=aliceryhl@google.com \
--cc=boqun@kernel.org \
--cc=brucer42@gmail.com \
--cc=gary@garyguo.net \
--cc=igor.korotin@linux.dev \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sre@kernel.org \
--cc=tamird@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.