Re: [PATCH v2 06/12] rust: pci: add a bind callback after installing driver data

["Danilo Krummrich" <dakr@kernel.org>]

On Fri Oct 23, 2026 at 5:40 PM CEST, Simon Song wrote:
> diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs
> index adc7e92d44e..1951b3c8a5c 100644
> --- a/rust/kernel/pci.rs
> +++ b/rust/kernel/pci.rs
> @@ -154,6 +154,13 @@ extern "C" fn probe_callback(
>              let data = T::probe(pdev, info);
>  
>              pdev.as_ref().set_drvdata(data)?;
> +            // SAFETY: `set_drvdata` installed the pinned `T::Data` above.
> +            let data = unsafe { pdev.as_ref().drvdata_borrow::<T::Data<'_>>() };
> +            if let Err(error) = T::bind(pdev, data) {
> +                // SAFETY: Failed bind leaves no callbacks borrowing the installed data.
> +                drop(unsafe { pdev.as_ref().drvdata_obtain::<T::Data<'_>>() });
> +                return Err(error);
> +            }
>              Ok(0)
>          })
>      }
> @@ -416,6 +423,15 @@ fn probe<'bound>(
>          id_info: Option<&'bound Self::IdInfo>,
>      ) -> impl PinInit<Self::Data<'bound>, Error> + 'bound;
>  
> +    /// Complete probe after the pinned driver data has been installed.
> +    ///
> +    /// Called with the PCI device lock held. On error, the data is dropped without calling
> +    /// [`Self::unbind`]. Any callbacks started here must be stopped before returning an error.
> +    fn bind<'bound>(dev: &Device<device::Core<'_>>, this: Pin<&Self::Data<'bound>>) -> Result {
> +        let _ = (dev, this);
> +        Ok(())
> +    }

No, please don't introduce a new bus callback for the sake of ordering
registrations against each other, it does not scale.

The answer is almost always to use a new registration data container and, where
needed, self-referential pin-init in order to represent ordering dependencies.

Fixed ordering imposed by bus callbacks falls apart with different driver needs,
whereas separate registration data containers and self-referential pin-init are
flexible and represent data dependencies and lifetimes directly.

IIUC, this comes down to the runtime PM implementation in this series, so please
base your code on the generic runtime PM work [1] from Beata (Cc) instead.

If you respin this series before Beata respins the runtime PM work, please take
my latest feedback on her series into account, since it may affect how this
series integrates with it.

I'd also suggest splitting out the runtime PM support as separate patches at the
end of this series, so we can start landing the rest independently.

[1] https://lore.kernel.org/all/20261026120523.526942-2-beata.michalska@arm.com/