Re: [PATCH v2 2/3] rust: platform: wire runtime PM callbacks

[Beata Michalska <beata.michalska@arm.com>]

On Tue, Aug 04, 2026 at 08:02:11AM +0000, Alice Ryhl wrote:
> On Tue, Jul 21, 2026 at 05:34:03PM +0200, Beata Michalska wrote:
> > Allow Rust platform drivers to expose runtime PM callbacks to the driver core.
> > 
> > The runtime PM abstraction builds a dev_pm_ops table for the concrete driver
> > implementation, but the platform bus still needs to receive that table through
> > struct platform_driver. Add an optional PM_OPS associated constant to
> > platform::Driver and initialize the coresponding C device_driver struct
> > accordingly during registration. The platform glue only wires the callback
> > table into the C driver model; ownership of the callback payload and
> > runtime PM teardown remain with the pm module.
> > 
> > Signed-off-by: Beata Michalska <beata.michalska@arm.com>
> > ---
> >  rust/kernel/platform.rs | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/rust/kernel/platform.rs b/rust/kernel/platform.rs
> > index d8d48f60b0b9..b7e422388634 100644
> > --- a/rust/kernel/platform.rs
> > +++ b/rust/kernel/platform.rs
> > @@ -72,6 +72,11 @@ unsafe fn register(
> >              None => core::ptr::null(),
> >          };
> >  
> > +        let pm_ops = match T::PM_OPS {
> > +            Some(ops) => ops,
> > +            None => core::ptr::null(),
> > +        };
> 
> This value is just any user-provided &bindings::pm_ops, which I think is
> too lax. There is no guarantee that the Registration and the PM_OPS
> table agree on what the type T is, which can lead to type confusion.
> 
Indeed, as stated in the commit message
> Most likely, you must instead give `trait Driver` an associated type
> saying "the PmOps type is this particular type", and then here you can
> do `Some(T::PM_OPS)` to actually get the associated table.
> 
> And then in the registration, you can further require that the types
> also match there. E.g., maybe make the registration generic over the
> Driver type and then the inner type T is just D::PmData or similar.
> 
I do need to ponder on that one a bit.

---
BR
Beata

> Alice
> 
> >          // SAFETY: It's safe to set the fields of `struct platform_driver` on initialization.
> >          unsafe {
> >              (*pdrv.get()).driver.name = name.as_char_ptr();
> > @@ -79,6 +84,7 @@ unsafe fn register(
> >              (*pdrv.get()).remove = Some(Self::remove_callback);
> >              (*pdrv.get()).driver.of_match_table = of_table;
> >              (*pdrv.get()).driver.acpi_match_table = acpi_table;
> > +            (*pdrv.get()).driver.pm = pm_ops;
> >          }
> >  
> >          // SAFETY: `pdrv` is guaranteed to be a valid `DriverType`.
> > @@ -222,6 +228,9 @@ pub trait Driver {
> >      /// The table of ACPI device ids supported by the driver.
> >      const ACPI_ID_TABLE: Option<acpi::IdTable<Self::IdInfo>> = None;
> >  
> > +    /// Runtime PM callbacks
> > +    const PM_OPS: Option<&'static bindings::dev_pm_ops> = None;
> > +
> >      /// Platform driver probe.
> >      ///
> >      /// Called when a new platform device is added or discovered.
> > -- 
> > 2.43.0
> >