From: Danilo Krummrich <dakr@kernel.org>
To: gregkh@linuxfoundation.org, rafael@kernel.org,
bhelgaas@google.com, ojeda@kernel.org, alex.gaynor@gmail.com,
boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com,
benno.lossin@proton.me, tmgross@umich.edu,
a.hindborg@samsung.com, aliceryhl@google.com, airlied@gmail.com,
fujita.tomonori@gmail.com, lina@asahilina.net,
pstanner@redhat.com, ajanulgu@redhat.com, lyude@redhat.com,
robh@kernel.org, daniel.almeida@collabora.com,
saravanak@google.com, dirk.behme@de.bosch.com, j@jannau.net,
fabien.parent@linaro.org, chrisi.schrefl@gmail.com
Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
Danilo Krummrich <dakr@kernel.org>,
Wedson Almeida Filho <wedsonaf@gmail.com>
Subject: [PATCH v5 02/16] rust: implement generic driver registration
Date: Tue, 10 Dec 2024 23:46:29 +0100 [thread overview]
Message-ID: <20241210224947.23804-3-dakr@kernel.org> (raw)
In-Reply-To: <20241210224947.23804-1-dakr@kernel.org>
Implement the generic `Registration` type and the `RegistrationOps`
trait.
The `Registration` structure is the common type that represents a driver
registration and is typically bound to the lifetime of a module. However,
it doesn't implement actual calls to the kernel's driver core to register
drivers itself.
Instead the `RegistrationOps` trait is provided to subsystems, which have
to implement `RegistrationOps::register` and
`RegistrationOps::unregister`. Subsystems have to provide an
implementation for both of those methods where the subsystem specific
variants to register / unregister a driver have to implemented.
For instance, the PCI subsystem would call __pci_register_driver() from
`RegistrationOps::register` and pci_unregister_driver() from
`DrvierOps::unregister`.
Co-developed-by: Wedson Almeida Filho <wedsonaf@gmail.com>
Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
---
MAINTAINERS | 1 +
rust/kernel/driver.rs | 116 ++++++++++++++++++++++++++++++++++++++++++
rust/kernel/lib.rs | 1 +
3 files changed, 118 insertions(+)
create mode 100644 rust/kernel/driver.rs
diff --git a/MAINTAINERS b/MAINTAINERS
index 17daa9ee9384..93fa6ec737c0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7033,6 +7033,7 @@ F: include/linux/kobj*
F: include/linux/property.h
F: lib/kobj*
F: rust/kernel/device.rs
+F: rust/kernel/driver.rs
DRIVERS FOR OMAP ADAPTIVE VOLTAGE SCALING (AVS)
M: Nishanth Menon <nm@ti.com>
diff --git a/rust/kernel/driver.rs b/rust/kernel/driver.rs
new file mode 100644
index 000000000000..ab0bb46fe2cc
--- /dev/null
+++ b/rust/kernel/driver.rs
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Generic support for drivers of different buses (e.g., PCI, Platform, Amba, etc.).
+//!
+//! Each bus / subsystem is expected to implement [`RegistrationOps`], which allows drivers to
+//! register using the [`Registration`] class.
+
+use crate::error::{Error, Result};
+use crate::{init::PinInit, str::CStr, try_pin_init, types::Opaque, ThisModule};
+use core::pin::Pin;
+use macros::{pin_data, pinned_drop};
+
+/// The [`RegistrationOps`] trait serves as generic interface for subsystems (e.g., PCI, Platform,
+/// Amba, etc.) to provide the corresponding subsystem specific implementation to register /
+/// unregister a driver of the particular type (`RegType`).
+///
+/// For instance, the PCI subsystem would set `RegType` to `bindings::pci_driver` and call
+/// `bindings::__pci_register_driver` from `RegistrationOps::register` and
+/// `bindings::pci_unregister_driver` from `RegistrationOps::unregister`.
+pub trait RegistrationOps {
+ /// The type that holds information about the registration. This is typically a struct defined
+ /// by the C portion of the kernel.
+ type RegType: Default;
+
+ /// Registers a driver.
+ ///
+ /// On success, `reg` must remain pinned and valid until the matching call to
+ /// [`RegistrationOps::unregister`].
+ fn register(
+ reg: &Opaque<Self::RegType>,
+ name: &'static CStr,
+ module: &'static ThisModule,
+ ) -> Result;
+
+ /// Unregisters a driver previously registered with [`RegistrationOps::register`].
+ fn unregister(reg: &Opaque<Self::RegType>);
+}
+
+/// A [`Registration`] is a generic type that represents the registration of some driver type (e.g.
+/// `bindings::pci_driver`). Therefore a [`Registration`] must be initialized with a type that
+/// implements the [`RegistrationOps`] trait, such that the generic `T::register` and
+/// `T::unregister` calls result in the subsystem specific registration calls.
+///
+///Once the `Registration` structure is dropped, the driver is unregistered.
+#[pin_data(PinnedDrop)]
+pub struct Registration<T: RegistrationOps> {
+ #[pin]
+ reg: Opaque<T::RegType>,
+}
+
+// SAFETY: `Registration` has no fields or methods accessible via `&Registration`, so it is safe to
+// share references to it with multiple threads as nothing can be done.
+unsafe impl<T: RegistrationOps> Sync for Registration<T> {}
+
+// SAFETY: Both registration and unregistration are implemented in C and safe to be performed from
+// any thread, so `Registration` is `Send`.
+unsafe impl<T: RegistrationOps> Send for Registration<T> {}
+
+impl<T: RegistrationOps> Registration<T> {
+ /// Creates a new instance of the registration object.
+ pub fn new(name: &'static CStr, module: &'static ThisModule) -> impl PinInit<Self, Error> {
+ try_pin_init!(Self {
+ reg <- Opaque::try_ffi_init(|ptr: *mut T::RegType| {
+ // SAFETY: `try_ffi_init` guarantees that `ptr` is valid for write.
+ unsafe { ptr.write(T::RegType::default()) };
+
+ // SAFETY: `try_ffi_init` guarantees that `ptr` is valid for write, and it has
+ // just been initialised above, so it's also valid for read.
+ let drv = unsafe { &*(ptr as *const Opaque<T::RegType>) };
+
+ T::register(drv, name, module)
+ }),
+ })
+ }
+}
+
+#[pinned_drop]
+impl<T: RegistrationOps> PinnedDrop for Registration<T> {
+ fn drop(self: Pin<&mut Self>) {
+ T::unregister(&self.reg);
+ }
+}
+
+/// A kernel module that only registers the given driver on init.
+///
+/// This is a helper struct to make it easier to define single-functionality modules, in this case,
+/// modules that offer a single driver.
+#[pin_data]
+pub struct Module<T: RegistrationOps> {
+ #[pin]
+ _driver: Registration<T>,
+}
+
+impl<T: RegistrationOps + Sync + Send> crate::InPlaceModule for Module<T> {
+ fn init(name: &'static CStr, module: &'static ThisModule) -> impl PinInit<Self, Error> {
+ try_pin_init!(Self {
+ _driver <- Registration::<T>::new(name, module),
+ })
+ }
+}
+
+/// Declares a kernel module that exposes a single driver.
+///
+/// It is meant to be used as a helper by other subsystems so they can more easily expose their own
+/// macros.
+#[macro_export]
+macro_rules! module_driver {
+ (<$gen_type:ident>, $driver_ops:ty, { type: $type:ty, $($f:tt)* }) => {
+ type Ops<$gen_type> = $driver_ops;
+ type ModuleType = $crate::driver::Module<Ops<$type>>;
+ $crate::prelude::module! {
+ type: ModuleType,
+ $($f)*
+ }
+ }
+}
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index 686db6aa3323..0a719396256f 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -35,6 +35,7 @@
mod build_assert;
pub mod cred;
pub mod device;
+pub mod driver;
pub mod error;
#[cfg(CONFIG_RUST_FW_LOADER_ABSTRACTIONS)]
pub mod firmware;
--
2.47.0
next prev parent reply other threads:[~2024-12-10 22:50 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-10 22:46 [PATCH v5 00/16] Device / Driver PCI / Platform Rust abstractions Danilo Krummrich
2024-12-10 22:46 ` [PATCH v5 01/16] rust: pass module name to `Module::init` Danilo Krummrich
2024-12-11 10:45 ` Greg KH
2024-12-11 10:48 ` Greg KH
2024-12-11 10:59 ` Greg KH
2024-12-11 11:05 ` Greg KH
2024-12-11 11:41 ` Miguel Ojeda
2024-12-11 12:43 ` Alice Ryhl
2024-12-11 12:22 ` Danilo Krummrich
2024-12-11 12:34 ` Danilo Krummrich
2024-12-11 13:14 ` Greg KH
2024-12-11 13:31 ` Danilo Krummrich
2024-12-11 13:34 ` Alice Ryhl
2024-12-11 14:29 ` Danilo Krummrich
2024-12-11 14:45 ` Alice Ryhl
2024-12-11 14:52 ` Danilo Krummrich
2024-12-11 14:55 ` Alice Ryhl
2024-12-11 15:03 ` Danilo Krummrich
2024-12-11 15:15 ` Alice Ryhl
2024-12-11 15:36 ` Danilo Krummrich
2024-12-11 15:53 ` Danilo Krummrich
2024-12-11 13:45 ` Greg KH
2024-12-11 14:21 ` Danilo Krummrich
2024-12-11 14:30 ` Greg KH
2024-12-10 22:46 ` Danilo Krummrich [this message]
2024-12-10 22:46 ` [PATCH v5 03/16] rust: implement `IdArray`, `IdTable` and `RawDeviceId` Danilo Krummrich
2024-12-10 22:46 ` [PATCH v5 04/16] rust: add rcu abstraction Danilo Krummrich
2024-12-11 18:47 ` Boqun Feng
2024-12-10 22:46 ` [PATCH v5 05/16] rust: types: add `Opaque::pin_init` Danilo Krummrich
2024-12-11 9:18 ` Alice Ryhl
2024-12-10 22:46 ` [PATCH v5 06/16] rust: add `Revocable` type Danilo Krummrich
2024-12-11 10:47 ` Benoît du Garreau
2024-12-11 10:57 ` Alice Ryhl
2024-12-10 22:46 ` [PATCH v5 07/16] rust: add `io::{Io, IoRaw}` base types Danilo Krummrich
2024-12-10 22:46 ` [PATCH v5 08/16] rust: add devres abstraction Danilo Krummrich
2024-12-10 22:46 ` [PATCH v5 09/16] rust: pci: add basic PCI device / driver abstractions Danilo Krummrich
2024-12-10 22:46 ` [PATCH v5 10/16] rust: pci: implement I/O mappable `pci::Bar` Danilo Krummrich
2024-12-10 22:46 ` [PATCH v5 11/16] samples: rust: add Rust PCI sample driver Danilo Krummrich
2024-12-16 5:07 ` kernel test robot
2024-12-10 22:46 ` [PATCH v5 12/16] rust: of: add `of::DeviceId` abstraction Danilo Krummrich
2024-12-10 22:46 ` [PATCH v5 13/16] rust: driver: implement `Adapter` Danilo Krummrich
2024-12-12 2:10 ` Fabien Parent
2024-12-10 22:46 ` [PATCH v5 14/16] rust: platform: add basic platform device / driver abstractions Danilo Krummrich
2024-12-11 15:27 ` Rob Herring
2024-12-10 22:46 ` [PATCH v5 15/16] samples: rust: add Rust platform sample driver Danilo Krummrich
2024-12-11 15:29 ` Rob Herring
2024-12-10 22:46 ` [PATCH v5 16/16] MAINTAINERS: add Danilo to DRIVER CORE Danilo Krummrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241210224947.23804-3-dakr@kernel.org \
--to=dakr@kernel.org \
--cc=a.hindborg@samsung.com \
--cc=airlied@gmail.com \
--cc=ajanulgu@redhat.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=chrisi.schrefl@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=dirk.behme@de.bosch.com \
--cc=fabien.parent@linaro.org \
--cc=fujita.tomonori@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=j@jannau.net \
--cc=lina@asahilina.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=ojeda@kernel.org \
--cc=pstanner@redhat.com \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=saravanak@google.com \
--cc=tmgross@umich.edu \
--cc=wedsonaf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.