- Feb 24, 2025
-
-
drm_mm provides a simple range allocator, useful for managing virtual address ranges. Add a Rust abstraction to expose this module to Rust drivers. The allocator will later be used by GPU drivers to allocate a range of VA addresses when mapping a given BO object. Signed-off-by:Asahi Lina <lina@asahilina.net>
-
- Jan 14, 2025
-
-
Danilo Krummrich authored
Add the initial driver stub of Nova, a Rust-based GSP-only driver for Nvidia GPUs. Nova, in the long term, is intended to serve as the successor of Nouveau for GSP-firmware-based GPUs. [1] As a stub driver Nova's focus is to make use of the most basic device / driver infrastructure required to build a DRM driver on the PCI bus and serve as demonstration example and justification for this infrastructure. In further consequence, the idea is to develop Nova continuously upstream, using those increments to lift further Rust abstractions and infrastructure upstream. Link: https://lore.kernel.org/dri-devel/Zfsj0_tb-0-tNrJy@cassiopeiae/T/#u [1] Signed-off-by:
Danilo Krummrich <dakr@kernel.org>
-
Asahi Lina authored
The DRM GEM subsystem is the DRM memory management subsystem used by most modern drivers. Add a Rust abstraction to allow Rust DRM driver implementations to use it. Signed-off-by:
Danilo Krummrich <dakr@redhat.com> Signed-off-by:
-
Asahi Lina authored
A DRM File is the DRM counterpart to a kernel file structure, representing an open DRM file descriptor. Add a Rust abstraction to allow drivers to implement their own File types that implement the DriverFile trait. Signed-off-by:
-
Danilo Krummrich authored
Implement the DRM driver `Registration`. The `Registration` structure is responsible to register and unregister a DRM driver. It makes use of the `Devres` container in order to allow the `Registration` to be owned by devres, such that it is automatically dropped (and the DRM driver unregistered) once the parent device is unbound. Co-developed-by:
-
Danilo Krummrich authored
Implement the abstraction for a `struct drm_device`. A `drm::device::Device` creates a static const `struct drm_driver` filled with the data from the `drm::drv::Driver` trait implementation of the actual driver creating the `drm::device::Device`. Co-developed-by:
-
Danilo Krummrich authored
Implement the DRM driver abstractions. The `Driver` trait provides the interface to the actual driver to fill in the driver specific data, such as the `DriverInfo`, driver features and IOCTLs. Co-developed-by:
-
Asahi Lina authored
Some traits exposed by the kernel crate may not be intended to be implemented by downstream modules. Add a Sealed trait to allow avoiding this using the sealed trait pattern. Signed-off-by:
-
Asahi Lina authored
DRM drivers need to be able to declare which driver-specific ioctls they support. Add an abstraction implementing the required types and a helper macro to generate the ioctl definition inside the DRM driver. Note that this macro is not usable until further bits of the abstraction are in place (but it will not fail to compile on its own, if not called). Signed-off-by:
-
Danilo Krummrich authored
The `RegistrationOps` trait holds some obligations to the caller and implementers. While being documented, the trait and the corresponding functions haven't been marked as unsafe. Hence, markt the trait and functions unsafe and add the corresponding safety comments. This patch does not include any fuctional changes. Reported-by:
Gary Guo <gary@garyguo.net> Closes: https://lore.kernel.org/rust-for-linux/20241224195821.3b43302b.gary@garyguo.net/ Signed-off-by:
-
Danilo Krummrich authored
The module entry of `io` falsely ended up in the "use" block instead of the "mod" block, hence move it to its correct location. Signed-off-by: -
Danilo Krummrich authored
The PCI abstractions do not actually depend on CONFIG_PCI_MSI; it also breaks drivers that only depend on CONFIG_PCI, hence drop it. While at it, move the module entry to its correct location. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501030744.4ucqC1cB-lkp@intel.com/ Fixes: 3a9c0919 ("rust: pci: add basic PCI device / driver abstractions") Signed-off-by:
-
Danilo Krummrich authored
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 authored
devm_remove_action() warns if the action to remove does not exist (anymore). The Rust devres abstraction, however, has a use-case to call devm_remove_action() at a point where it can't be guaranteed that the corresponding action hasn't been released yet. In particular, an instance of `Devres<T>` may be dropped after the action has been released. So far, `Devres<T>` worked around this by keeping the inner type alive. Hence, add devm_remove_action_nowarn(), which returns an error code if the action has been removed already. A subsequent patch uses devm_remove_action_nowarn() to remove the action when `Devres<T>` is dropped. Signed-off-by: -
Danilo Krummrich authored
Let's keep an eye on the Rust abstractions; add myself as reviewer to DRIVER CORE. Signed-off-by: -
Danilo Krummrich authored
Add a sample Rust platform driver illustrating the usage of the platform bus abstractions. This driver probes through either a match of device / driver name or a match within the OF ID table. Reviewed-by:
Rob Herring (Arm) <robh@kernel.org> Signed-off-by:
-
Danilo Krummrich authored
Implement the basic platform bus abstractions required to write a basic platform driver. This includes the following data structures: The `platform::Driver` trait represents the interface to the driver and provides `platform::Driver::probe` for the driver to implement. The `platform::Device` abstraction represents a `struct platform_device`. In order to provide the platform bus specific parts to a generic `driver::Registration` the `driver::RegistrationOps` trait is implemented by `platform::Adapter`. Reviewed-by:
-
Danilo Krummrich authored
In order to not duplicate code in bus specific implementations (e.g. platform), implement a generic `driver::Adapter` to represent the connection of matched drivers and devices. Bus specific `Adapter` implementations can simply implement this trait to inherit generic functionality, such as matching OF or ACPI device IDs and ID table entries. Suggested-by:
-
Danilo Krummrich authored
`of::DeviceId` is an abstraction around `struct of_device_id`. This is used by subsequent patches, in particular the platform bus abstractions, to create OF device ID tables. Reviewed-by:
-
Danilo Krummrich authored
This commit adds a sample Rust PCI driver for QEMU's "pci-testdev" device. To enable this device QEMU has to be called with `-device pci-testdev`. The same driver shows how to use the PCI device / driver abstractions, as well as how to request and map PCI BARs, including a short sequence of MMIO operations. Signed-off-by: -
Danilo Krummrich authored
Implement `pci::Bar`, `pci::Device::iomap_region` and `pci::Device::iomap_region_sized` to allow for I/O mappings of PCI BARs. To ensure that a `pci::Bar`, and hence the I/O memory mapping, can't out-live the PCI device, the `pci::Bar` type is always embedded into a `Devres` container, such that the `pci::Bar` is revoked once the device is unbound and hence the I/O mapped memory is unmapped. A `pci::Bar` can be requested with (`pci::Device::iomap_region_sized`) or without (`pci::Device::iomap_region`) a const generic representing the minimal requested size of the I/O mapped memory region. In case of the latter only runtime checked I/O reads / writes are possible. Co-developed-by:
Philipp Stanner <pstanner@redhat.com> Signed-off-by:
-
Danilo Krummrich authored
Implement the basic PCI abstractions required to write a basic PCI driver. This includes the following data structures: The `pci::Driver` trait represents the interface to the driver and provides `pci::Driver::probe` for the driver to implement. The `pci::Device` abstraction represents a `struct pci_dev` and provides abstractions for common functions, such as `pci::Device::set_master`. In order to provide the PCI specific parts to a generic `driver::Registration` the `driver::RegistrationOps` trait is implemented by `pci::Adapter`. `pci::DeviceId` implements PCI device IDs based on the generic `device_id::RawDevceId` abstraction. Co-developed-by:
FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by:
-
Danilo Krummrich authored
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 authored
I/O memory is typically either mapped through direct calls to ioremap() or subsystem / bus specific ones such as pci_iomap(). Even though subsystem / bus specific functions to map I/O memory are based on ioremap() / iounmap() it is not desirable to re-implement them in Rust. Instead, implement a base type for I/O mapped memory, which generically provides the corresponding accessors, such as `Io::readb` or `Io:try_readb`. `Io` supports an optional const generic, such that a driver can indicate the minimal expected and required size of the mapping at compile time. Correspondingly, calls to the 'non-try' accessors, support compile time checks of the I/O memory offset to read / write, while the 'try' accessors, provide boundary checks on runtime. `IoRaw` is meant to be embedded into a structure (e.g. pci::Bar or io::IoMem) which creates the actual I/O memory mapping and initializes `IoRaw` accordingly. To ensure that I/O mapped memory can't out-live the device it may be bound to, subsystems must embed the corresponding I/O memory type (e.g. pci::Bar) into a `Devres` container, such that it gets revoked once the device is unbound. Reviewed-by:
Alice Ryhl <aliceryhl@google.com> Tested-by:
Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by:
-
Wedson Almeida Filho authored
Revocable allows access to objects to be safely revoked at run time. This is useful, for example, for resources allocated during device probe; when the device is removed, the driver should stop accessing the device resources even if another state is kept in memory due to existing references (i.e., device context data is ref-counted and has a non-zero refcount after removal of the device). Signed-off-by:
Wedson Almeida Filho <wedsonaf@gmail.com> Co-developed-by:
-
Danilo Krummrich authored
Analogous to `Opaque::new` add `Opaque::pin_init`, which instead of a value `T` takes a `PinInit<T>` and returns a `PinInit<Opaque<T>>`. Reviewed-by:
-
Wedson Almeida Filho authored
Add a simple abstraction to guard critical code sections with an rcu read lock. Reviewed-by:
Boqun Feng <boqun.feng@gmail.com> Signed-off-by:
-
Danilo Krummrich authored
Most subsystems use some kind of ID to match devices and drivers. Hence, we have to provide Rust drivers an abstraction to register an ID table for the driver to match. Generally, those IDs are subsystem specific and hence need to be implemented by the corresponding subsystem. However, the `IdArray`, `IdTable` and `RawDeviceId` types provide a generalized implementation that makes the life of subsystems easier to do so. Co-developed-by:
Fabien Parent <fabien.parent@linaro.org> Signed-off-by:
-
Danilo Krummrich authored
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:
-
Danilo Krummrich authored
In order to access static metadata of a Rust kernel module, add the `ModuleMetadata` trait. In particular, this trait provides the name of a Rust kernel module as specified by the `module!` macro. Signed-off-by:
-
- Jan 13, 2025
-
-
Filipe Xavier authored
The UserSliceReader::read_all function is currently restricted to use only Vec with the kmalloc allocator. However, there is no reason for this limitation. This patch generalizes the function to accept any Vec regardless of the allocator used. There's a use-case for a KVVec in Binder to avoid maximum sizes for a certain array. Link: https://github.com/Rust-for-Linux/linux/issues/1136 Signed-off-by:
Filipe Xavier <felipeaggger@gmail.com> Reviewed-by:
Miguel Ojeda <ojeda@kernel.org>
-
Alice Ryhl authoredPreviously, the `ForeignOwnable` trait had a method called `borrow_mut` that was intended to provide mutable access to the inner value. However, the method accidentally made it possible to change the address of the object being modified, which usually isn't what we want. (And when we want that, it can be done by calling `from_foreign` and `into_foreign`, like how the old `borrow_mut` was implemented.) In this patch, we introduce an alternate definition of `borrow_mut` that solves the previous problem. Conceptually, given a pointer type `P` that implements `ForeignOwnable`, the `borrow_mut` method gives you the same kind of access as an `&mut P` would, except that it does not let you change the pointer `P` itself. This is analogous to how the existing `borrow` method provides the same kind of access to the inner value as an `&P`. Note that for types like `Arc`, having an `&mut Arc<T>` only gives you immutable access to the inner `T`. This is because mutable references assume exclusive access, but there might be other handles to the same reference counted value, so the access isn't exclusive. The `Arc` type implements this by making `borrow_mut` return the same type as `borrow`. Signed-off-by:
Benno Lossin <benno.lossin@proton.me> Reviewed-by:
Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by:
Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by:
Tamir Duberstein <tamird@gmail.com> Acked-by:
-
Tamir Duberstein authored
`{into,from}_foreign` before `borrow` is slightly more logical. This removes an inconsistency with `kbox.rs` which already uses this ordering. Reviewed-by: -
Tamir Duberstein authored
It is slightly more convenient to operate on mut pointers, and this also properly conveys the desired ownership semantics of the trait. Reviewed-by:
-
Tamir Duberstein authored
The new SAFETY comment style is taken from existing comments in `deref` and `drop. Reviewed-by:
-
Tamir Duberstein authored
Replace `as` casts with `cast{,_mut}` calls which are a bit safer. In one instance, remove an unnecessary `as` cast without replacement. Reviewed-by: -
Tamir Duberstein authored
There is no need to check (and panic on violations of) the safety requirements on `ForeignOwnable` functions. Avoiding the check is consistent with the implementation of `ForeignOwnable` for `Box`. Reviewed-by:
-
Xiangfei Ding authored
The `kernel` crate relies on both `coerce_unsized` and `dispatch_from_dyn` unstable features. Alice Ryhl has proposed [1] the introduction of the unstable macro `SmartPointer` to reduce such dependence, along with a RFC patch [2]. Since Rust 1.81.0 this macro, later renamed to `CoercePointee` in Rust 1.84.0 [3], has been fully implemented with the naming discussion resolved. This feature is now on track to stabilization in the language. In order to do so, we shall start using this macro in the `kernel` crate to prove the functionality and utility of the macro as the justification of its stabilization. This patch makes this switch in such a way that the crate remains backward compatible with older Rust compiler versions, via the new Kconfig option `RUSTC_HAS_COERCE_POINTEE`. A minimal demonstration example is added to the `samples/rust/rust_print_main.rs` module. Link: https://rust-lang.github.io/rfcs/3621-derive-smart-pointer.html [1] Link: https://lore.kernel.org/all/20240823-derive-smart-pointer-v1-1-53769cd37239@google.com/ [2] Link: https://github.com/rust-lang/rust/pull/131284 [3] Signed-off-by:
Xiangfei Ding <dingxiangfei2009@gmail.com> Reviewed-by:
Fiona Behrens <me@kloenk.dev> Reviewed-by:
-
Jimmy Ostler authored
Add a rustdoc example and Kunit test to the `ArrayLayout` struct's `ArrayLayout::new()` function. This patch depends on the first patch in this series in order for the KUnit test to compile. Suggested-by:
Jimmy Ostler <jtostler1@gmail.com> Link: https://lore.kernel.org/r/f1564da5bcaa6be87aee312767a1d1694a03d1b7.1734674670.git.jtostler1@gmail.com [ Added periods to example comments. Reworded title. - Miguel ] Signed-off-by:
-
Jimmy Ostler authored
Change documentation imports to use `kernel::alloc::AllocError`, because `KBox::new()` now returns that, instead of the `core`'s `AllocError`. Reviewed-by:
-
