mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: lyude@redhat.com
To: Daniel Almeida <daniel.almeida@collabora.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	 rust-for-linux@vger.kernel.org,
	Danilo Krummrich <dakr@kernel.org>,
	 nouveau@lists.freedesktop.org, Miguel Ojeda <ojeda@kernel.org>,
	Simona Vetter	 <simona@ffwll.ch>,
	Alice Ryhl <aliceryhl@google.com>,
	Shankari Anand	 <shankari.ak0208@gmail.com>,
	David Airlie <airlied@gmail.com>,
	Benno Lossin	 <lossin@kernel.org>,
	Asahi Lina <lina+kernel@asahilina.net>
Subject: Re: [PATCH v3 2/3] rust/drm: Don't setup private driver data until registration
Date: Fri, 23 Jan 2026 12:00:28 -0500	[thread overview]
Message-ID: <47cbb2bb4462331e5ffa56da488d8ffab9a5fcd7.camel@redhat.com> (raw)
In-Reply-To: <E3CBBAB1-4EED-4052-B9DC-AAEB58D67265@collabora.com>

On Thu, 2026-01-22 at 22:52 -0300, Daniel Almeida wrote:
> > @@ -254,7 +240,15 @@ pub fn new(dev: &device::Device, data: impl
> > PinInit<T::Data, Error>) -> Result<S
> > #[repr(C)]
> > pub struct Device<T: drm::Driver, C: DeviceContext = Registered> {
> >      dev: Opaque<bindings::drm_device>,
> > -    data: T::Data,
> > +
> > +    /// Keeps track of whether we've initialized the device data
> > yet.
> > +    pub(crate) data_is_init: AtomicBool,
> 
> Why don’t we make the data a member of the Registered context?

A couple of different reasons. For one: not having it embedded as part
of Device would complicate trying to go from the device's private data
using container_of! to the actual Device struct, which isn't great for
workqueues.

The other much more important reason is that Registered isn't going to
be the only typestate that has access to the driver's private data in
the future. With KMS, nearly all of the modesetting callbacks for a
driver can be invoked before userspace registration. E.g. consider a
modesetting driver that needs to perform a modeset pre-registration so
that the hardware is in a known good state before being exposed to
userspace.

To clarify what this looks like: you'll recall that I made a diagram
showing a high-level overview of the DRM initialization process for the
documentation for DeviceContext. The second stage in that diagram,
which I'm currently calling Init, is the context that we're going to
need to eventually add a typestate for.

FWIW, this is more or less what the flow will look like with this new
context. Indenting indicates calling down to a function from within the
function above

 * UnregisteredDevice::new(d: device::Device) -> UnregisteredDevice<T>
    - // Creates Crtcs, Connectors, etc.
      KmsDriver::probe(d: &UninitializedKmsDevice)
 * // The driver sets stuff up
 * Registration::new_foreign_owned(
     dev: UnregisteredDevice,
     data: impl PinInit<T::Data>
   ):
    - // Initialize `data`, so driver data is ready at this point
    - KmsDriver::pre_registration_init(d: &Device<T, Init>)
    - // Perform actual userspace registration

If it wasn't clear too: this means tyr won't really need to do anything
when we add the new DeviceContext typestate :)

> 
> > +
> > +    /// The Driver's private data.
> > +    ///
> > +    /// This must only be written to from
> > [`drm::Registration::new`].
> > +    pub(crate) data: UnsafeCell<MaybeUninit<T::Data>>,
> > +
> >      _ctx: PhantomData<C>,


  reply	other threads:[~2026-01-23 17:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-22 22:46 [PATCH v3 0/3] Introduce DeviceContext Lyude Paul
2026-01-22 22:46 ` [PATCH v3 1/3] rust/drm: " Lyude Paul
2026-01-23  1:41   ` Daniel Almeida
2026-01-23 17:09   ` Danilo Krummrich
2026-01-22 22:46 ` [PATCH v3 2/3] rust/drm: Don't setup private driver data until registration Lyude Paul
2026-01-23  1:52   ` Daniel Almeida
2026-01-23 17:00     ` lyude [this message]
2026-01-22 22:46 ` [PATCH v3 3/3] rust/drm/gem: Use DeviceContext with GEM objects Lyude Paul
2026-01-23  1:56   ` Daniel Almeida
2026-01-23 22:52     ` lyude

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=47cbb2bb4462331e5ffa56da488d8ffab9a5fcd7.camel@redhat.com \
    --to=lyude@redhat.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=lina+kernel@asahilina.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=shankari.ak0208@gmail.com \
    --cc=simona@ffwll.ch \
    /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

all inboxes | Powered by JetHome®