All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Timur Tabi" <ttabi@nvidia.com>
Cc: Gary Guo <gary@garyguo.net>, Alice Ryhl <aliceryhl@google.com>,
	mmaurer@google.com, Danilo Krummrich <dakr@kernel.org>,
	Joel Fernandes <joelagnelf@nvidia.com>,
	rust-for-linux@vger.kernel.org, nouveau@lists.freedesktop.org
Subject: Re: [PATCH v8 5/7] gpu: nova-core: use pin projection in method boot()
Date: Fri, 13 Mar 2026 11:13:25 +0900	[thread overview]
Message-ID: <DH1AHR75GRMP.3K4RVG31XF24A@nvidia.com> (raw)
In-Reply-To: <20260310220000.1897166-6-ttabi@nvidia.com>

On Wed Mar 11, 2026 at 6:59 AM JST, Timur Tabi wrote:
> Struct Gsp in gsp.rs is tagged with #[pin_data], which allows any of its
> fields to be pinned (i.e. with #[pin]).  When #[pin] is added to any
> field in a #[pin_data] struct, fields can no longer be directly accessed
> via normal field access.  Instead, pin projection must be used to access
> those fields.
>
> Currently, no fields are pinned, but that will change.  The boot() method
> receives self: Pin<&mut Self>. When struct Gsp contains any pinned
> fields, direct field access like self.cmdq is not allowed through
> Pin<&mut Self>, as Pin prevents obtaining &mut Self to protect pinned
> data from being moved.
>
> Use pin projection via self.as_mut().project() to access struct fields.
> The project() method, generated by #[pin_data], returns a projection
> struct providing &mut references to non-pinned fields, enabling mutable
> access while preserving pin invariants.
>
> Signed-off-by: Timur Tabi <ttabi@nvidia.com>

This is going to clash with the command queue locking series [1], which
we will want to merge first. Can you rebase on top of it? I suspect you
might even just need to drop this patch and things will work.

[1] https://lore.kernel.org/all/20260310-cmdq-locking-v4-0-4e5c4753c408@nvidia.com/


WARNING: multiple messages have this Message-ID (diff)
From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Timur Tabi" <ttabi@nvidia.com>
Cc: "Gary Guo" <gary@garyguo.net>,
	"Alice Ryhl" <aliceryhl@google.com>, <mmaurer@google.com>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Joel Fernandes" <joelagnelf@nvidia.com>,
	<rust-for-linux@vger.kernel.org>, <nouveau@lists.freedesktop.org>
Subject: Re: [PATCH v8 5/7] gpu: nova-core: use pin projection in method boot()
Date: Fri, 13 Mar 2026 11:13:25 +0900	[thread overview]
Message-ID: <DH1AHR75GRMP.3K4RVG31XF24A@nvidia.com> (raw)
In-Reply-To: <20260310220000.1897166-6-ttabi@nvidia.com>

On Wed Mar 11, 2026 at 6:59 AM JST, Timur Tabi wrote:
> Struct Gsp in gsp.rs is tagged with #[pin_data], which allows any of its
> fields to be pinned (i.e. with #[pin]).  When #[pin] is added to any
> field in a #[pin_data] struct, fields can no longer be directly accessed
> via normal field access.  Instead, pin projection must be used to access
> those fields.
>
> Currently, no fields are pinned, but that will change.  The boot() method
> receives self: Pin<&mut Self>. When struct Gsp contains any pinned
> fields, direct field access like self.cmdq is not allowed through
> Pin<&mut Self>, as Pin prevents obtaining &mut Self to protect pinned
> data from being moved.
>
> Use pin projection via self.as_mut().project() to access struct fields.
> The project() method, generated by #[pin_data], returns a projection
> struct providing &mut references to non-pinned fields, enabling mutable
> access while preserving pin invariants.
>
> Signed-off-by: Timur Tabi <ttabi@nvidia.com>

This is going to clash with the command queue locking series [1], which
we will want to merge first. Can you rebase on top of it? I suspect you
might even just need to drop this patch and things will work.

[1] https://lore.kernel.org/all/20260310-cmdq-locking-v4-0-4e5c4753c408@nvidia.com/


  reply	other threads:[~2026-03-13  2:13 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-10 21:59 [PATCH v8 0/7] gpu: nova-core: expose the logging buffers via debugfs Timur Tabi
2026-03-10 21:59 ` [PATCH v8 1/7] rust: device: add device name method Timur Tabi
2026-03-10 22:05   ` Alice Ryhl
2026-03-10 22:05     ` Alice Ryhl
2026-03-13  2:10   ` Alexandre Courbot
2026-03-13  2:10     ` Alexandre Courbot
2026-03-10 21:59 ` [PATCH v8 2/7] rust: uaccess: add write_dma() for copying from DMA buffers to userspace Timur Tabi
2026-03-11  5:48   ` kernel test robot
2026-03-13  2:11   ` Alexandre Courbot
2026-03-13  2:11     ` Alexandre Courbot
2026-03-10 21:59 ` [PATCH v8 3/7] rust: dma: implement BinaryWriter for CoherentAllocation<u8> Timur Tabi
2026-03-13  2:11   ` Alexandre Courbot
2026-03-13  2:11     ` Alexandre Courbot
2026-03-14  2:05     ` Timur Tabi
2026-03-14  2:05       ` Timur Tabi
2026-03-15  5:11       ` Alexandre Courbot
2026-03-15  5:11         ` Alexandre Courbot
2026-03-15 18:57         ` Timur Tabi
2026-03-15 18:57           ` Timur Tabi
2026-03-16  3:44           ` Alexandre Courbot
2026-03-16  3:44             ` Alexandre Courbot
2026-03-10 21:59 ` [PATCH v8 4/7] gpu: nova-core: Replace module_pci_driver! with explicit module init Timur Tabi
2026-03-10 21:59 ` [PATCH v8 5/7] gpu: nova-core: use pin projection in method boot() Timur Tabi
2026-03-13  2:13   ` Alexandre Courbot [this message]
2026-03-13  2:13     ` Alexandre Courbot
2026-03-14  2:20     ` Timur Tabi
2026-03-14  2:20       ` Timur Tabi
2026-03-10 21:59 ` [PATCH v8 6/7] gpu: nova-core: create debugfs root in module init Timur Tabi
2026-03-10 22:00 ` [PATCH v8 7/7] gpu: nova-core: create GSP-RM logging buffers debugfs entries Timur Tabi
2026-03-10 22:20 ` [PATCH v8 0/7] gpu: nova-core: expose the logging buffers via debugfs John Hubbard
2026-03-12  3:50 ` John Hubbard

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=DH1AHR75GRMP.3K4RVG31XF24A@nvidia.com \
    --to=acourbot@nvidia.com \
    --cc=aliceryhl@google.com \
    --cc=dakr@kernel.org \
    --cc=gary@garyguo.net \
    --cc=joelagnelf@nvidia.com \
    --cc=mmaurer@google.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=ttabi@nvidia.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.