linux.git/rust/kernel/device.rs, branch v7.2-rc1

rust: device: make Core and CoreInternal lifetime-parameterized

2026-05-27T14:22:42+00:00

Device references in probe callbacks are scoped to the callback,
not the full binding duration. Add a lifetime parameter to Core and
CoreInternal to accurately represent this in the type system.

Suggested-by: Gary Guo 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Alexandre Courbot 
Reviewed-by: Eliot Courtney 
Reviewed-by: Gary Guo 
Link: https://patch.msgid.link/20260525202921.124698-12-dakr@kernel.org
Signed-off-by: Danilo Krummrich

rust: device: implement Sync for Device

2026-05-27T14:22:41+00:00

Implement Sync for Device in addition to Device.

Device uses the same underlying struct device as Device;
Bound is a zero-sized type-state marker that does not affect thread
safety.

This is needed for types that hold &'bound Device, such as
io::mem::IoMem, to be Send.

Reviewed-by: Alexandre Courbot 
Reviewed-by: Gary Guo 
Reviewed-by: Greg Kroah-Hartman 
Acked-by: Uwe Kleine-König 
Tested-by: Dirk Behme 
Link: https://patch.msgid.link/20260525202921.124698-11-dakr@kernel.org
Signed-off-by: Danilo Krummrich

rust: driver: move 'static bounds to constructor

2026-05-27T14:22:41+00:00

With the ForeignOwnable lifetime change, the 'static bound is no longer
necessary on the drvdata methods or bus adapter impls. Move it to the
Registration constructor instead.

Reviewed-by: Alexandre Courbot 
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Gary Guo 
Link: https://patch.msgid.link/20260525202921.124698-4-dakr@kernel.org
Co-developed-by: Danilo Krummrich 
Signed-off-by: Danilo Krummrich

rust: driver core: remove drvdata() and driver_type

2026-05-11T13:26:12+00:00

When drvdata() was introduced in commit 6f61a2637abe ("rust: device:
introduce Device::drvdata()"), its commit message already noted that a
direct accessor to the driver's bus device private data is not commonly
required -- bus callbacks provide access through &self, and other entry
points (IRQs, workqueues, IOCTLs, etc.) carry their own private data.

The sole motivation for drvdata() was inter-driver interaction -- an
auxiliary driver deriving the parent's bus device private data from the
parent device.

However, drvdata() exposes the driver's bus device private data beyond
the driver's own scope. This creates ordering constraints; for instance
drvdata may not be set yet when the first caller of drvdata() can
appear. It also forces the driver's bus device private data to outlive
all registrations that access it, which causes unnecessary
complications.

Private data should be private to the entity that issues it, i.e. bus
device private data belongs to bus callbacks, class device private data
to class callbacks, IRQ private data to the IRQ handler, etc.

With registration-private data now available through the auxiliary bus,
there is no remaining user of drvdata(), thus remove it.

Reviewed-by: Alice Ryhl 
Link: https://patch.msgid.link/20260505152400.3905096-4-dakr@kernel.org
Signed-off-by: Danilo Krummrich

rust: device: add device name method

2026-03-24T22:51:23+00:00

Add a name() method to the `Device` type, which returns a CStr that
contains the device name.

Signed-off-by: Timur Tabi 
Reviewed-by: Alice Ryhl 
Reviewed-by: Alexandre Courbot 
Reviewed-by: Gary Guo 
Tested-by: John Hubbard 
Tested-by: Eliot Courtney 
Link: https://patch.msgid.link/20260319212658.2541610-2-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich

rust: dma: add generalized container for types other than slices

2026-03-23T21:15:03+00:00

Currently, `CoherentAllocation` is concecptually a DMA coherent container
of a slice of `[T]` of runtime-checked length. Generalize it by creating
`dma::Coherent` which can hold any value of `T`.
`Coherent::alloc_with_attrs` is implemented but not yet exposed, as I
believe we should not expose the way to obtain an uninitialized coherent
region.

`Coherent<[T]>` provides a `len` method instead of the previous `count()`
method to be consistent with methods on slices.

The existing type is re-defined as a type alias of `Coherent<[T]>` to ease
transition. Methods in use are not yet removed.

Signed-off-by: Gary Guo 
Reviewed-by: Alice Ryhl 
Reviewed-by: Alexandre Courbot 
Link: https://patch.msgid.link/20260320194626.36263-3-dakr@kernel.org
Signed-off-by: Danilo Krummrich

Merge tag 'v6.19-rc7' into driver-core-next

2026-01-26T12:23:52+00:00

We need the driver-core fixes in here as well to build on top of.

Signed-off-by: Danilo Krummrich

rust: device: support `dev_printk` on all devices

2026-01-24T00:12:49+00:00

Currently, `dev_*` only works on the core `Device`, but not on any other
bus or class device objects. This causes a pattern of
`dev_info!(pdev.as_ref())` which is not ideal.

This adds support of using these devices directly with `dev_*` macros, by
adding `AsRef` call inside the macro. To make sure we can still use just
`kernel::device::Device`, as `AsRef` implementation is added for it; this
is typical for types that is designed to use with `AsRef` anyway, for
example, `str` implements `AsRef` and `Path` implements `AsRef`.

Signed-off-by: Gary Guo 
Link: https://patch.msgid.link/20260123175854.176735-1-gary@kernel.org
Signed-off-by: Danilo Krummrich

rust: driver: drop device private data post unbind

2026-01-16T00:17:29+00:00

Currently, the driver's device private data is allocated and initialized
from driver core code called from bus abstractions after the driver's
probe() callback returned the corresponding initializer.

Similarly, the driver's device private data is dropped within the
remove() callback of bus abstractions after calling the remove()
callback of the corresponding driver.

However, commit 6f61a2637abe ("rust: device: introduce
Device::drvdata()") introduced an accessor for the driver's device
private data for a Device, i.e. a device that is currently bound
to a driver.

Obviously, this is in conflict with dropping the driver's device private
data in remove(), since a device can not be considered to be fully
unbound after remove() has finished:

We also have to consider registrations guarded by devres - such as IRQ
or class device registrations - which are torn down after remove() in
devres_release_all().

Thus, it can happen that, for instance, a class device or IRQ callback
still calls Device::drvdata(), which then runs concurrently to remove()
(which sets dev->driver_data to NULL and drops the driver's device
private data), before devres_release_all() started to tear down the
corresponding registration. This is because devres guarded registrations
can, as expected, access the corresponding Device that defines
their scope.

In C it simply is the driver's responsibility to ensure that its device
private data is freed after e.g. an IRQ registration is unregistered.

Typically, C drivers achieve this by allocating their device private data
with e.g. devm_kzalloc() before doing anything else, i.e. before e.g.
registering an IRQ with devm_request_threaded_irq(), relying on the
reverse order cleanup of devres.

Technically, we could do something similar in Rust. However, the
resulting code would be pretty messy:

In Rust we have to differentiate between allocated but uninitialized
memory and initialized memory in the type system. Thus, we would need to
somehow keep track of whether the driver's device private data object
has been initialized (i.e. probe() was successful and returned a valid
initializer for this memory) and conditionally call the destructor of
the corresponding object when it is freed.

This is because we'd need to allocate and register the memory of the
driver's device private data *before* it is initialized by the
initializer returned by the driver's probe() callback, because the
driver could already register devres guarded registrations within
probe() outside of the driver's device private data initializer.

Luckily there is a much simpler solution: Instead of dropping the
driver's device private data at the end of remove(), we just drop it
after the device has been fully unbound, i.e. after all devres callbacks
have been processed.

For this, we introduce a new post_unbind() callback private to the
driver-core, i.e. the callback is neither exposed to drivers, nor to bus
abstractions.

This way, the driver-core code can simply continue to conditionally
allocate the memory for the driver's device private data when the
driver's initializer is returned from probe() - no change needed - and
drop it when the driver-core code receives the post_unbind() callback.

Closes: https://lore.kernel.org/all/DEZMS6Y4A7XE.XE7EUBT5SJFJ@kernel.org/
Fixes: 6f61a2637abe ("rust: device: introduce Device::drvdata()")
Acked-by: Alice Ryhl 
Acked-by: Greg Kroah-Hartman 
Acked-by: Igor Korotin 
Link: https://patch.msgid.link/20260107103511.570525-7-dakr@kernel.org
[ Remove #ifdef CONFIG_RUST, rename post_unbind() to post_unbind_rust().
 - Danilo]
Signed-off-by: Danilo Krummrich

Merge tag 'v6.19-rc5' into driver-core-next

2026-01-12T12:33:24+00:00

We need the driver-core fixes in here as well to build on top of.

Signed-off-by: Danilo Krummrich