Re: [RFC PATCH 2/3] rust: power_supply: add power supply class abstraction

Bruce Robertson <[email protected]>
Newsgroups org.kernel.vger.linux-i2c,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pm,org.kernel.vger.rust-for-linux
Message-ID <[email protected]>
On Thu, Jul 09, 2026 at 09:04:00 +0000, Alice Ryhl wrote:
> > +/// 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>?

Yes, it should. That also lines up with Danilo's comment on the i2c
side of this series that I/O-capable operations need at least the
Bound device context. Will fix in v2.

Taking &Device<Bound> also helps with a lifetime problem the cover
letter flagged: the trampoline currently recovers the driver's private
data via device drvdata, which the i2c core only sets after probe()
returns, while power_supply_register() exposes sysfs before that. For
v2 I plan to pass the driver data through power_supply_config::drv_data
at registration time instead, so the callback never depends on drvdata
ordering, and to add a Sync bound on Driver since get_property() can be
called concurrently.

> 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.

Agreed. I'll rework it as Registration::new(dev: &Device<Bound>, ...)
in v2, following the existing Registration patterns in the tree, and
look at tying the descriptor lifetime to devres while I'm there rather
than relying on Drop ordering alone.

Thanks for the review.

Apologies for slow response. Was wilderness camping.

Bruce
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.