Skip to content

Commit 82b3644

Browse files
author
Danilo Krummrich
committed
device: rust: expand documentation for DeviceContext
Expand the documentation around DeviceContext states and types, in order to provide detailed information about their purpose and relationship with each other. Reviewed-by: Greg Kroah-Hartman <[email protected]> Reviewed-by: Alexandre Courbot <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Daniel Almeida <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Fix two minor typos. - Danilo ] Signed-off-by: Danilo Krummrich <[email protected]>
1 parent eb5ca90 commit 82b3644

File tree

1 file changed

+58
-11
lines changed

1 file changed

+58
-11
lines changed

rust/kernel/device.rs

Lines changed: 58 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -311,28 +311,75 @@ unsafe impl Send for Device {}
311311
// synchronization in `struct device`.
312312
unsafe impl Sync for Device {}
313313

314-
/// Marker trait for the context of a bus specific device.
314+
/// Marker trait for the context or scope of a bus specific device.
315315
///
316-
/// Some functions of a bus specific device should only be called from a certain context, i.e. bus
317-
/// callbacks, such as `probe()`.
316+
/// [`DeviceContext`] is a marker trait for types representing the context of a bus specific
317+
/// [`Device`].
318318
///
319-
/// This is the marker trait for structures representing the context of a bus specific device.
319+
/// The specific device context types are: [`CoreInternal`], [`Core`], [`Bound`] and [`Normal`].
320+
///
321+
/// [`DeviceContext`] types are hierarchical, which means that there is a strict hierarchy that
322+
/// defines which [`DeviceContext`] type can be derived from another. For instance, any
323+
/// [`Device<Core>`] can dereference to a [`Device<Bound>`].
324+
///
325+
/// The following enumeration illustrates the dereference hierarchy of [`DeviceContext`] types.
326+
///
327+
/// - [`CoreInternal`] => [`Core`] => [`Bound`] => [`Normal`]
328+
///
329+
/// Bus devices can automatically implement the dereference hierarchy by using
330+
/// [`impl_device_context_deref`].
331+
///
332+
/// Note that the guarantee for a [`Device`] reference to have a certain [`DeviceContext`] comes
333+
/// from the specific scope the [`Device`] reference is valid in.
334+
///
335+
/// [`impl_device_context_deref`]: kernel::impl_device_context_deref
320336
pub trait DeviceContext: private::Sealed {}
321337

322-
/// The [`Normal`] context is the context of a bus specific device when it is not an argument of
323-
/// any bus callback.
338+
/// The [`Normal`] context is the default [`DeviceContext`] of any [`Device`].
339+
///
340+
/// The normal context does not indicate any specific context. Any `Device<Ctx>` is also a valid
341+
/// [`Device<Normal>`]. It is the only [`DeviceContext`] for which it is valid to implement
342+
/// [`AlwaysRefCounted`] for.
343+
///
344+
/// [`AlwaysRefCounted`]: kernel::types::AlwaysRefCounted
324345
pub struct Normal;
325346

326-
/// The [`Core`] context is the context of a bus specific device when it is supplied as argument of
327-
/// any of the bus callbacks, such as `probe()`.
347+
/// The [`Core`] context is the context of a bus specific device when it appears as argument of
348+
/// any bus specific callback, such as `probe()`.
349+
///
350+
/// The core context indicates that the [`Device<Core>`] reference's scope is limited to the bus
351+
/// callback it appears in. It is intended to be used for synchronization purposes. Bus device
352+
/// implementations can implement methods for [`Device<Core>`], such that they can only be called
353+
/// from bus callbacks.
328354
pub struct Core;
329355

330-
/// Semantically the same as [`Core`] but reserved for internal usage of the corresponding bus
356+
/// Semantically the same as [`Core`], but reserved for internal usage of the corresponding bus
357+
/// abstraction.
358+
///
359+
/// The internal core context is intended to be used in exactly the same way as the [`Core`]
360+
/// context, with the difference that this [`DeviceContext`] is internal to the corresponding bus
331361
/// abstraction.
362+
///
363+
/// This context mainly exists to share generic [`Device`] infrastructure that should only be called
364+
/// from bus callbacks with bus abstractions, but without making them accessible for drivers.
332365
pub struct CoreInternal;
333366

334-
/// The [`Bound`] context is the context of a bus specific device reference when it is guaranteed to
335-
/// be bound for the duration of its lifetime.
367+
/// The [`Bound`] context is the [`DeviceContext`] of a bus specific device when it is guaranteed to
368+
/// be bound to a driver.
369+
///
370+
/// The bound context indicates that for the entire duration of the lifetime of a [`Device<Bound>`]
371+
/// reference, the [`Device`] is guaranteed to be bound to a driver.
372+
///
373+
/// Some APIs, such as [`dma::CoherentAllocation`] or [`Devres`] rely on the [`Device`] to be bound,
374+
/// which can be proven with the [`Bound`] device context.
375+
///
376+
/// Any abstraction that can guarantee a scope where the corresponding bus device is bound, should
377+
/// provide a [`Device<Bound>`] reference to its users for this scope. This allows users to benefit
378+
/// from optimizations for accessing device resources, see also [`Devres::access`].
379+
///
380+
/// [`Devres`]: kernel::devres::Devres
381+
/// [`Devres::access`]: kernel::devres::Devres::access
382+
/// [`dma::CoherentAllocation`]: kernel::dma::CoherentAllocation
336383
pub struct Bound;
337384

338385
mod private {

0 commit comments

Comments
 (0)