Re: [PATCH v18 3/4] rust: faux: Allow retrieving a bound Device

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The `Registration` struct's `# Invariants` documentation was updated with a new invariant, but the `// INVARIANT:` comment in the `Registration::new` constructor was not updated to explain why this new invariant is satisfied.
- [Low] Typo in the new type invariant comment: it incorrectly states the object is 'bound to a device' instead of 'bound to a driver'.
--

commit d541fc9c1199eb4e3a390c6348b6b03f9492aacc
Author: Lyude Paul <lyude@redhat.com>

rust: faux: Allow retrieving a bound Device

This commit updates faux::Registration to implement AsRef for a bound
device instead of a generic device. It also adds a new invariant to the
Registration struct to document that the object is proof of a driver being
bound to the device.

> diff --git a/rust/kernel/faux.rs b/rust/kernel/faux.rs
> index 43b4974f48cd2..20ab638885354 100644
> --- a/rust/kernel/faux.rs
> +++ b/rust/kernel/faux.rs
> @@ -25,7 +25,8 @@
>  ///
>  /// # Invariants
>  ///
> -/// `self.0` always holds a valid pointer to an initialized and registered [`struct faux_device`].
> +/// - `self.0` always holds a valid pointer to an initialized and registered [`struct faux_device`].
> +/// - This object is proof that the object described by this `Registration` is bound to a device.

[Severity: Low]
This isn't a bug, but there appears to be a typo here. The commit message
states that the Registration object is proof that "a driver is bound to the
device". Should this invariant say it is bound to a "driver" instead of
a "device"?

[Severity: Low]
Since a new invariant was added to the documentation here, does the
// INVARIANT: comment in Registration::new() also need to be updated to
explain why this new invariant is satisfied?

Currently, the comment in Registration::new() only explains the first
invariant:

    // INVARIANT: The device will remain registered until faux_device_destroy()
    // is called, which happens in our Drop implementation.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604192740.659240-1-lyude@redhat.com?part=3