From: Danilo Krummrich <dakr@kernel.org>
To: gregkh@linuxfoundation.org, rafael@kernel.org,
acourbot@nvidia.com, aliceryhl@google.com,
david.m.ertman@intel.com, ira.weiny@intel.com, leon@kernel.org,
ojeda@kernel.org, boqun@kernel.org, gary@garyguo.net,
bjorn3_gh@protonmail.com, lossin@kernel.org,
a.hindborg@kernel.org, tmgross@umich.edu
Cc: driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
nova-gpu@lists.linux.dev, dri-devel@lists.freedesktop.org,
rust-for-linux@vger.kernel.org,
Danilo Krummrich <dakr@kernel.org>
Subject: [PATCH v2 0/3] rust: auxiliary: replace drvdata() with registration data
Date: Tue, 5 May 2026 17:23:06 +0200 [thread overview]
Message-ID: <20260505152400.3905096-1-dakr@kernel.org> (raw)
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, e.g. a parent
driver deriving its bus device private data from the child driver via the
auxiliary bus.
However, drvdata() exposes the driver's bus device private data beyond the
driver's own scope. This creates ordering constraints -- drvdata may not be set
yet when the first caller of drvdata() can appear -- and forces the driver's bus
device private data to outlive all registrations that access it; a requirement
that causes unnecessary complications.
Private data should be private to the entity that issues it; bus device private
data belongs to bus callbacks, class device private data to class callbacks, IRQ
private data to the IRQ handler, etc.
This series replaces drvdata() with a dedicated registration_data pointer on
struct auxiliary_device. The parent stores its private data explicitly during
registration; the data is private to the registration and lives as long as the
Registration object.
On teardown, Registration::drop() first triggers auxiliary_device_delete()
(unbinding the child), then frees the registration data. Ordering constraints
are structural -- the child's lifecycle is scoped to the registration by
construction, not by convention.
With no remaining use case for drvdata(), drvdata(), match_type_id(),
set_type_id() and struct driver_type are removed.
This is a prerequisite for [1], which builds on the removal of drvdata() to
enable Higher-Ranked Lifetime Types (HRT) for Rust device drivers.
[1] https://lore.kernel.org/driver-core/20260427221155.2144848-1-dakr@kernel.org/
Changes in v2:
- Introduce Box::zeroed()
- Add Sync bound to Registration<T> impl block
- Use KBox::zeroed() instead of KBox::new(Opaque::zeroed(), ...)
- Use drop() instead of let _ = { ... }
- Fix invariant doc reference
Danilo Krummrich (3):
rust: alloc: add Box::zeroed()
rust: auxiliary: add registration data to auxiliary devices
rust: driver core: remove drvdata() and driver_type
drivers/base/base.h | 16 --
drivers/gpu/nova-core/driver.rs | 10 +-
include/linux/auxiliary_bus.h | 4 +
rust/kernel/alloc/kbox.rs | 22 +++
rust/kernel/auxiliary.rs | 208 ++++++++++++++++++--------
rust/kernel/device.rs | 60 --------
samples/rust/rust_driver_auxiliary.rs | 40 +++--
7 files changed, 202 insertions(+), 158 deletions(-)
base-commit: 30c878ed169983190f77940594f8ba8948debe6b
--
2.54.0
next reply other threads:[~2026-05-05 15:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 15:23 Danilo Krummrich [this message]
2026-05-05 15:23 ` [PATCH v2 1/3] rust: alloc: add Box::zeroed() Danilo Krummrich
2026-05-05 15:48 ` Alice Ryhl
2026-05-05 20:04 ` Danilo Krummrich
2026-05-05 20:06 ` Gary Guo
2026-05-05 20:10 ` Danilo Krummrich
2026-05-05 15:23 ` [PATCH v2 2/3] rust: auxiliary: add registration data to auxiliary devices Danilo Krummrich
2026-05-06 12:42 ` Alice Ryhl
2026-05-06 13:41 ` Gary Guo
2026-05-05 15:23 ` [PATCH v2 3/3] rust: driver core: remove drvdata() and driver_type 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=20260505152400.3905096-1-dakr@kernel.org \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=david.m.ertman@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=driver-core@lists.linux.dev \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=ira.weiny@intel.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox