[PATCH 00/24] rust: device: Higher-Ranked Lifetime Types for device drivers

Danilo Krummrich posted 24 patches 1 month, 2 weeks ago
There is a newer version of this series
drivers/base/dd.c                     |   2 +-
drivers/cpufreq/rcpufreq_dt.rs        |  10 +-
drivers/gpu/drm/nova/driver.rs        |   9 +-
drivers/gpu/drm/tyr/driver.rs         |  24 ++-
drivers/gpu/drm/tyr/gpu.rs            |  62 ++++---
drivers/gpu/drm/tyr/regs.rs           |  21 +--
drivers/gpu/nova-core/driver.rs       |  48 ++---
drivers/gpu/nova-core/fb.rs           |  31 ++--
drivers/gpu/nova-core/gpu.rs          |  32 +---
drivers/gpu/nova-core/nova_core.rs    |   4 +-
drivers/pwm/pwm_th1520.rs             |  14 +-
include/linux/device/driver.h         |   4 +-
rust/Makefile                         |   1 +
rust/kernel/auxiliary.rs              | 144 ++++++++++-----
rust/kernel/cpufreq.rs                |   8 +-
rust/kernel/device.rs                 |  84 ++++++---
rust/kernel/devres.rs                 |  31 +++-
rust/kernel/driver.rs                 |  44 +++--
rust/kernel/i2c.rs                    | 121 ++++++++-----
rust/kernel/io/mem.rs                 | 118 ++++++-------
rust/kernel/pci.rs                    |  88 +++++++---
rust/kernel/pci/io.rs                 |  50 +++---
rust/kernel/platform.rs               | 101 +++++++----
rust/kernel/types.rs                  |   4 +
rust/kernel/types/for_lt.rs           | 117 +++++++++++++
rust/kernel/usb.rs                    |  93 ++++++----
rust/macros/for_lt.rs                 | 242 ++++++++++++++++++++++++++
rust/macros/lib.rs                    |  12 ++
samples/rust/rust_debugfs.rs          |  10 +-
samples/rust/rust_dma.rs              |   9 +-
samples/rust/rust_driver_auxiliary.rs |  53 ++++--
samples/rust/rust_driver_i2c.rs       |  18 +-
samples/rust/rust_driver_pci.rs       |  93 +++++-----
samples/rust/rust_driver_platform.rs  |  12 +-
samples/rust/rust_driver_usb.rs       |  14 +-
samples/rust/rust_i2c_client.rs       |  12 +-
samples/rust/rust_soc.rs              |  12 +-
37 files changed, 1182 insertions(+), 570 deletions(-)
create mode 100644 rust/kernel/types/for_lt.rs
create mode 100644 rust/macros/for_lt.rs
[PATCH 00/24] rust: device: Higher-Ranked Lifetime Types for device drivers
Posted by Danilo Krummrich 1 month, 2 weeks ago
Currently, Rust device drivers access device resources such as PCI BAR mappings
and I/O memory regions through Devres<T>.

Devres::access() provides zero-overhead access by taking a &Device<Bound>
reference as proof that the device is still bound. Since a &Device<Bound> is
available in almost all contexts by design, Devres is mostly a type-system level
proof that the resource is valid, but it can also be used from scopes without
this guarantee through its try_access() accessor.

This works well in general, but has a few limitations:

  - Every access to a device resource goes through Devres::access(), which
    despite zero cost, adds boilerplate to every access site.

  - Destructors do not receive a &Device<Bound>, so they must use try_access(),
    which can fail. In practice the access succeeds if teardown ordering is
    correct, but the type system can't express this, forcing drivers to handle a
    failure path that should never be taken.

  - Sharing a resource across components (e.g. passing a BAR to a sub-component)
    requires Arc<Devres<T>>.

  - Device references must be stored as ARef<Device> rather than plain &Device
    borrows.

These limitations stem from the driver's bus device private data being 'static
-- the driver struct cannot borrow from the device reference it receives in
probe(), even though it structurally cannot outlive the device binding.

This series introduces Higher-Ranked Lifetime Types (HRT) for Rust device
drivers. An HRT is a type that is generic over a lifetime -- it does not have a
fixed lifetime, but can be instantiated with any lifetime chosen by the caller.

Rust does not directly support types that are generic over a lifetime as type
parameters; the ForLt trait (contributed by Gary Guo) encodes this internally.

The module_*_driver! macros handle the wrapping, so driver authors just write
struct MyDriver<'a> and impl Driver<'a>.

With HRT, driver structs carry a lifetime parameter tied to the device binding
scope -- the interval of a bus device being bound to a driver. Device resources
like pci::Bar<'a> and IoMem<'a> are handed out with this lifetime, so the
compiler enforces at build time that they do not escape the binding scope.

Before:

	struct MyDriver {
	    pdev: ARef<pci::Device>,
	    bar: Devres<pci::Bar<BAR_SIZE>>,
	}

	let io = self.bar.access(dev)?;
	io.read32(OFFSET);

After:

	struct MyDriver<'a> {
	    pdev: &'a pci::Device,
	    bar: pci::Bar<'a, BAR_SIZE>,
	}

	self.bar.read32(OFFSET);

Lifetime-parameterized device resources can be put into a Devres at any point
via Bar::into_devres() / IoMem::into_devres(), providing the exact same
semantics as before. This is useful for resources shared across subsystem
boundaries where revocation is needed.

This also synergizes with the upcoming self-referential initialization support
in pin-init, which allows one field of the driver struct to borrow another
during initialization without unsafe code.

The same pattern is applied to auxiliary device registration data as a first
example beyond bus device private data. Registration<F: ForLt> can hold
lifetime-parameterized data tied to the parent driver's binding scope. Since the
auxiliary bus guarantees that the parent remains bound while the auxiliary
device is registered, the registration data can safely borrow the parent's
device resources.

More generally, binding resource lifetimes to a registration scope applies to
every registration that is scoped to a driver binding -- auxiliary devices,
class devices, IRQ handlers, workqueues.

A follow-up series extends this to class device registrations, starting with
DRM, so that class device callbacks (IOCTLs, etc.) can safely access device
resources through the separate registration data bound to the registration's
lifetime without Devres indirection.

The series contains a few driver patches for reference, indicated by the REF
suffix.

Thanks to Gary for coming up with the ForLt implementation; thanks to Alice for
the early discussions around lifetime-parameterized private data that helped
shape the direction of this work.

This series depends on [1].

[1] https://lore.kernel.org/driver-core/20260427221002.2143861-1-dakr@kernel.org/

Danilo Krummrich (23):
  rust: driver core: drop drvdata before devres release
  rust: devres: add ForLt support to Devres
  rust: device: generalize drvdata methods over ForLt
  rust: driver: make Adapter trait lifetime-parameterized
  rust: pci: implement Sync for Device<Bound>
  rust: platform: implement Sync for Device<Bound>
  rust: auxiliary: implement Sync for Device<Bound>
  rust: usb: implement Sync for Device<Bound>
  rust: device: implement Sync for Device<Bound>
  rust: pci: make Driver trait lifetime-parameterized
  rust: platform: make Driver trait lifetime-parameterized
  rust: auxiliary: make Driver trait lifetime-parameterized
  rust: auxiliary: generalize Registration over ForLt
  samples: rust: rust_driver_auxiliary: showcase lifetime-bound
    registration data
  rust: usb: make Driver trait lifetime-parameterized
  rust: i2c: make Driver trait lifetime-parameterized
  rust: pci: make Bar lifetime-parameterized
  rust: io: make IoMem and ExclusiveIoMem lifetime-parameterized
  samples: rust: rust_driver_pci: use HRT lifetime for Bar
  gpu: nova-core: use HRT lifetime for Bar
  gpu: nova-core: unregister sysmem flush page from Drop
  gpu: nova-core: replace ARef<Device> with &'a Device in SysmemFlush
  gpu: drm: tyr: use HRT lifetime for IoMem

Gary Guo (1):
  rust: types: add `ForLt` trait for higher-ranked lifetime support

 drivers/base/dd.c                     |   2 +-
 drivers/cpufreq/rcpufreq_dt.rs        |  10 +-
 drivers/gpu/drm/nova/driver.rs        |   9 +-
 drivers/gpu/drm/tyr/driver.rs         |  24 ++-
 drivers/gpu/drm/tyr/gpu.rs            |  62 ++++---
 drivers/gpu/drm/tyr/regs.rs           |  21 +--
 drivers/gpu/nova-core/driver.rs       |  48 ++---
 drivers/gpu/nova-core/fb.rs           |  31 ++--
 drivers/gpu/nova-core/gpu.rs          |  32 +---
 drivers/gpu/nova-core/nova_core.rs    |   4 +-
 drivers/pwm/pwm_th1520.rs             |  14 +-
 include/linux/device/driver.h         |   4 +-
 rust/Makefile                         |   1 +
 rust/kernel/auxiliary.rs              | 144 ++++++++++-----
 rust/kernel/cpufreq.rs                |   8 +-
 rust/kernel/device.rs                 |  84 ++++++---
 rust/kernel/devres.rs                 |  31 +++-
 rust/kernel/driver.rs                 |  44 +++--
 rust/kernel/i2c.rs                    | 121 ++++++++-----
 rust/kernel/io/mem.rs                 | 118 ++++++-------
 rust/kernel/pci.rs                    |  88 +++++++---
 rust/kernel/pci/io.rs                 |  50 +++---
 rust/kernel/platform.rs               | 101 +++++++----
 rust/kernel/types.rs                  |   4 +
 rust/kernel/types/for_lt.rs           | 117 +++++++++++++
 rust/kernel/usb.rs                    |  93 ++++++----
 rust/macros/for_lt.rs                 | 242 ++++++++++++++++++++++++++
 rust/macros/lib.rs                    |  12 ++
 samples/rust/rust_debugfs.rs          |  10 +-
 samples/rust/rust_dma.rs              |   9 +-
 samples/rust/rust_driver_auxiliary.rs |  53 ++++--
 samples/rust/rust_driver_i2c.rs       |  18 +-
 samples/rust/rust_driver_pci.rs       |  93 +++++-----
 samples/rust/rust_driver_platform.rs  |  12 +-
 samples/rust/rust_driver_usb.rs       |  14 +-
 samples/rust/rust_i2c_client.rs       |  12 +-
 samples/rust/rust_soc.rs              |  12 +-
 37 files changed, 1182 insertions(+), 570 deletions(-)
 create mode 100644 rust/kernel/types/for_lt.rs
 create mode 100644 rust/macros/for_lt.rs

-- 
2.54.0
Re: [PATCH 00/24] rust: device: Higher-Ranked Lifetime Types for device drivers
Posted by Uwe Kleine-König 1 month, 2 weeks ago
Hello,

On Tue, Apr 28, 2026 at 12:10:58AM +0200, Danilo Krummrich wrote:
>  drivers/pwm/pwm_th1520.rs             |  14 +-

I didn't try to understand what you do here, but there is nothing
scheduled so far for the pwm_th1520 driver in my tree, so

Acked-by: Uwe Kleine-König <ukleinek@kernel.org>

for patches #12 and #19 touching this driver for merging through (I
guess) the rust tree. Maybe Michal wants to say something about the
actual change.

Best regards
Uwe
Re: [PATCH 00/24] rust: device: Higher-Ranked Lifetime Types for device drivers
Posted by Danilo Krummrich 1 month, 2 weeks ago
On Tue Apr 28, 2026 at 11:37 AM CEST, Uwe Kleine-König wrote:
> I didn't try to understand what you do here, but there is nothing
> scheduled so far for the pwm_th1520 driver in my tree, so

Compressed to one sentence, it is driver core plumbing to allow bus device
private data (and registration data) to represent their lifetime being tied to
the device / driver lifecycle with native Rust lifetimes.

Drivers can take advantage of this subsequently; for reference see the nova-core
changes at the end of this series.

> Acked-by: Uwe Kleine-König <ukleinek@kernel.org>
>
> for patches #12 and #19 touching this driver for merging through (I
> guess) the rust tree.

Thanks -- as mentioned, it is driver core plumbing, so eventually I'll take it
through the driver core tree.

- Danilo
Re: [PATCH 00/24] rust: device: Higher-Ranked Lifetime Types for device drivers
Posted by Alice Ryhl 1 month, 2 weeks ago
Super cool to see this!

On Tue, Apr 28, 2026 at 12:10:58AM +0200, Danilo Krummrich wrote:
> Before:
> 
> 	struct MyDriver {
> 	    pdev: ARef<pci::Device>,
> 	    bar: Devres<pci::Bar<BAR_SIZE>>,
> 	}
> 
> 	let io = self.bar.access(dev)?;
> 	io.read32(OFFSET);
> 
> After:
> 
> 	struct MyDriver<'a> {
> 	    pdev: &'a pci::Device,
> 	    bar: pci::Bar<'a, BAR_SIZE>,
> 	}
> 
> 	self.bar.read32(OFFSET);

I think we should establish a convention for how to name the lifetime
early. Using just the generic name 'a is probably not ideal.

How about using 'dev for lifetimes that correspond to the lifetime of
the device being bound?

Alice
Re: [PATCH 00/24] rust: device: Higher-Ranked Lifetime Types for device drivers
Posted by Danilo Krummrich 1 month, 2 weeks ago
On Thu Apr 30, 2026 at 11:14 AM CEST, Alice Ryhl wrote:
> Super cool to see this!
>
> On Tue, Apr 28, 2026 at 12:10:58AM +0200, Danilo Krummrich wrote:
>> Before:
>> 
>> 	struct MyDriver {
>> 	    pdev: ARef<pci::Device>,
>> 	    bar: Devres<pci::Bar<BAR_SIZE>>,
>> 	}
>> 
>> 	let io = self.bar.access(dev)?;
>> 	io.read32(OFFSET);
>> 
>> After:
>> 
>> 	struct MyDriver<'a> {
>> 	    pdev: &'a pci::Device,
>> 	    bar: pci::Bar<'a, BAR_SIZE>,
>> 	}
>> 
>> 	self.bar.read32(OFFSET);
>
> I think we should establish a convention for how to name the lifetime
> early. Using just the generic name 'a is probably not ideal.
>
> How about using 'dev for lifetimes that correspond to the lifetime of
> the device being bound?

I'd rather not go for 'dev, as it could be confused with the lifetime of the
struct device itself, which is reference counted and independent from the device
/ driver binding lifecycle.

People already confuse this all the time, so I'd rather go for 'bound, which is
more precise, but could be a bit long on the other hand.
Re: [PATCH 00/24] rust: device: Higher-Ranked Lifetime Types for device drivers
Posted by Alexandre Courbot 1 month, 2 weeks ago
On Thu Apr 30, 2026 at 6:14 PM JST, Alice Ryhl wrote:
> Super cool to see this!
>
> On Tue, Apr 28, 2026 at 12:10:58AM +0200, Danilo Krummrich wrote:
>> Before:
>> 
>> 	struct MyDriver {
>> 	    pdev: ARef<pci::Device>,
>> 	    bar: Devres<pci::Bar<BAR_SIZE>>,
>> 	}
>> 
>> 	let io = self.bar.access(dev)?;
>> 	io.read32(OFFSET);
>> 
>> After:
>> 
>> 	struct MyDriver<'a> {
>> 	    pdev: &'a pci::Device,
>> 	    bar: pci::Bar<'a, BAR_SIZE>,
>> 	}
>> 
>> 	self.bar.read32(OFFSET);
>
> I think we should establish a convention for how to name the lifetime
> early. Using just the generic name 'a is probably not ideal.
>
> How about using 'dev for lifetimes that correspond to the lifetime of
> the device being bound?

Good idea, it's not obvious what this lifetime covers at first sight.
I'd even hammer it a bit more in the documentation as it is quite an
essential point.