public inbox for rust-for-linux@vger.kernel.org
 help / color / mirror / Atom feed
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>
Subject: Re: [PATCH 0/2] rust: auxiliary: replace drvdata() with registration data
Date: Tue, 28 Apr 2026 00:14:54 +0200	[thread overview]
Message-ID: <DI4A86QOY8BW.10B14POU8D2XA@kernel.org> (raw)
In-Reply-To: <20260427221002.2143861-1-dakr@kernel.org>

On Tue Apr 28, 2026 at 12:09 AM CEST, Danilo Krummrich wrote:
> 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] Posted as a reply to this series.

https://lore.kernel.org/driver-core/20260427221155.2144848-1-dakr@kernel.org/

>
> Danilo Krummrich (2):
>   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/auxiliary.rs              | 208 ++++++++++++++++++--------
>  rust/kernel/device.rs                 |  60 --------
>  samples/rust/rust_driver_auxiliary.rs |  40 +++--
>  6 files changed, 180 insertions(+), 158 deletions(-)
>
>
> base-commit: a7cc262a11354ab104b8e55c21200d099d141bc7
> -- 
> 2.54.0


      parent reply	other threads:[~2026-04-27 22:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-27 22:09 [PATCH 0/2] rust: auxiliary: replace drvdata() with registration data Danilo Krummrich
2026-04-27 22:09 ` [PATCH 1/2] rust: auxiliary: add registration data to auxiliary devices Danilo Krummrich
2026-04-27 22:09 ` [PATCH 2/2] rust: driver core: remove drvdata() and driver_type Danilo Krummrich
2026-04-27 22:14 ` Danilo Krummrich [this message]

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=DI4A86QOY8BW.10B14POU8D2XA@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