The doctest requires `CONFIG_PCI`:
error[E0432]: unresolved import `kernel::pci`
--> rust/doctests_kernel_generated.rs:2689:44
|
2689 | use kernel::{device::Core, devres::Devres, pci};
| ^^^ no `pci` in the root
|
note: found an item that was configured out
--> rust/kernel/lib.rs:96:9
note: the item is gated here
--> rust/kernel/lib.rs:95:1
Thus conditionally compile it (which still checks the syntax).
Fixes: f301cb978c ("rust: devres: implement Devres::access()")
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://lore.kernel.org/r/20250511182533.1016163-1-ojeda@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Implement a direct accessor for the data stored within the Devres for
cases where we can prove that we own a reference to a Device<Bound>
(i.e. a bound device) of the same device that was used to create the
corresponding Devres container.
Usually, when accessing the data stored within a Devres container, it is
not clear whether the data has been revoked already due to the device
being unbound and, hence, we have to try whether the access is possible
and subsequently keep holding the RCU read lock for the duration of the
access.
However, when we can prove that we hold a reference to Device<Bound>
matching the device the Devres container has been created with, we can
guarantee that the device is not unbound for the duration of the
lifetime of the Device<Bound> reference and, hence, it is not possible
for the data within the Devres container to be revoked.
Therefore, in this case, we can bypass the atomic check and the RCU read
lock, which is a great optimization and simplification for drivers.
Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
Link: https://lore.kernel.org/r/20250428140137.468709-3-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Require the Bound device context to be able to a new Devres container.
This ensures that we can't register devres callbacks for unbound
devices.
Link: https://lore.kernel.org/r/20250413173758.12068-9-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
So far `DevresInner` is kept alive, even if `Devres` is dropped until
the devres callback is executed to avoid a WARN() when the action has
been released already.
With the introduction of devm_remove_action_nowarn() we can remove the
action in `Devres::drop`, handle the case where the action has been
released already and hence also free `DevresInner`.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20250107122609.8135-2-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a Rust abstraction for the kernel's devres (device resource
management) implementation.
The Devres type acts as a container to manage the lifetime and
accessibility of device bound resources. Therefore it registers a
devres callback and revokes access to the resource on invocation.
Users of the Devres abstraction can simply free the corresponding
resources in their Drop implementation, which is invoked when either the
Devres instance goes out of scope or the devres callback leads to the
resource being revoked, which implies a call to drop_in_place().
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://lore.kernel.org/r/20241219170425.12036-9-dakr@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
