From: "Danilo Krummrich" <dakr@kernel.org>
To: "Gary Guo" <gary@garyguo.net>
Cc: <aliceryhl@google.com>, <acourbot@nvidia.com>, <ojeda@kernel.org>,
<boqun@kernel.org>, <bjorn3_gh@protonmail.com>,
<lossin@kernel.org>, <a.hindborg@kernel.org>, <tmgross@umich.edu>,
<abdiel.janulgue@gmail.com>, <daniel.almeida@collabora.com>,
<robin.murphy@arm.com>, <driver-core@lists.linux.dev>,
<nouveau@lists.freedesktop.org>,
<dri-devel@lists.freedesktop.org>,
<rust-for-linux@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 8/8] gpu: nova-core: convert to new dma::Coherent API
Date: Sat, 21 Mar 2026 19:22:39 +0100 [thread overview]
Message-ID: <DH8O47F2GM1Z.3H3E13RSKIV22@kernel.org> (raw)
In-Reply-To: <DH8M5QZKZETW.3TA4YS1SBAXDP@garyguo.net>
On 3/21/26 5:50 PM, Gary Guo wrote:
> It looks like with Alex's "gpu: nova-core: create falcon firmware DMA objects
> lazily" landed, all others users of the old API are now gone.
Good catch.
> So this line could be dropped and `impl CoherentAllocation` and the type alias
> can be removed after this patch.
I will drop the line on apply and add the below patch to remove
CoherentAllocation.
- Danilo
commit e96bc0b65bec48ac0f1cf2fc15b39c1b26b9d973 (HEAD -> drm-rust-next)
Author: Danilo Krummrich <dakr@kernel.org>
Date: Sat Mar 21 19:18:08 2026 +0100
rust: dma: remove dma::CoherentAllocation<T>
Now that everything has been converted to the new dma::Coherent<T> API,
remove dma::CoherentAllocation<T>.
Suggested-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
index 6d2bec52806b..779d4babab9a 100644
--- a/rust/kernel/dma.rs
+++ b/rust/kernel/dma.rs
@@ -841,156 +841,6 @@ pub fn len(&self) -> usize {
}
}
-// Type alias for compatibility.
-#[doc(hidden)]
-pub type CoherentAllocation<T> = Coherent<[T]>;
-
-impl<T: AsBytes + FromBytes> CoherentAllocation<T> {
- /// Allocates a region of `size_of::<T> * count` of coherent memory.
- ///
- /// # Examples
- ///
- /// ```
- /// # use kernel::device::{Bound, Device};
- /// use kernel::dma::{attrs::*, CoherentAllocation};
- ///
- /// # fn test(dev: &Device<Bound>) -> Result {
- /// let c: CoherentAllocation<u64> =
- /// CoherentAllocation::alloc_attrs(dev, 4, GFP_KERNEL, DMA_ATTR_NO_WARN)?;
- /// # Ok::<(), Error>(()) }
- /// ```
- pub fn alloc_attrs(
- dev: &device::Device<Bound>,
- count: usize,
- gfp_flags: kernel::alloc::Flags,
- dma_attrs: Attrs,
- ) -> Result<CoherentAllocation<T>> {
- Coherent::alloc_slice_with_attrs(dev, count, gfp_flags, dma_attrs)
- }
-
- /// Performs the same functionality as [`CoherentAllocation::alloc_attrs`], except the
- /// `dma_attrs` is 0 by default.
- pub fn alloc_coherent(
- dev: &device::Device<Bound>,
- count: usize,
- gfp_flags: kernel::alloc::Flags,
- ) -> Result<CoherentAllocation<T>> {
- CoherentAllocation::alloc_attrs(dev, count, gfp_flags, Attrs(0))
- }
-
- /// Returns the base address to the allocated region in the CPU's virtual address space.
- pub fn start_ptr(&self) -> *const T {
- self.as_ptr().cast()
- }
-
- /// Returns the base address to the allocated region in the CPU's virtual address space as
- /// a mutable pointer.
- pub fn start_ptr_mut(&mut self) -> *mut T {
- self.as_mut_ptr().cast()
- }
-
- /// Returns a DMA handle starting at `offset` (in units of `T`) which may be given to the
- /// device as the DMA address base of the region.
- ///
- /// Returns `EINVAL` if `offset` is not within the bounds of the allocation.
- pub fn dma_handle_with_offset(&self, offset: usize) -> Result<DmaAddress> {
- if offset >= self.len() {
- Err(EINVAL)
- } else {
- Ok(self.dma_handle + (offset * core::mem::size_of::<T>()) as DmaAddress)
- }
- }
-
- /// Common helper to validate a range applied from the allocated region in the CPU's virtual
- /// address space.
- fn validate_range(&self, offset: usize, count: usize) -> Result {
- if offset.checked_add(count).ok_or(EOVERFLOW)? > self.len() {
- return Err(EINVAL);
- }
- Ok(())
- }
-
- /// Returns the data from the region starting from `offset` as a slice.
- /// `offset` and `count` are in units of `T`, not the number of bytes.
- ///
- /// For ringbuffer type of r/w access or use-cases where the pointer to the live data is needed,
- /// [`CoherentAllocation::start_ptr`] or [`CoherentAllocation::start_ptr_mut`] could be used
- /// instead.
- ///
- /// # Safety
- ///
- /// * Callers must ensure that the device does not read/write to/from memory while the returned
- /// slice is live.
- /// * Callers must ensure that this call does not race with a write to the same region while
- /// the returned slice is live.
- pub unsafe fn as_slice(&self, offset: usize, count: usize) -> Result<&[T]> {
- self.validate_range(offset, count)?;
- // SAFETY:
- // - The pointer is valid due to type invariant on `CoherentAllocation`,
- // we've just checked that the range and index is within bounds. The immutability of the
- // data is also guaranteed by the safety requirements of the function.
- // - `offset + count` can't overflow since it is smaller than `self.count` and we've checked
- // that `self.count` won't overflow early in the constructor.
- Ok(unsafe { core::slice::from_raw_parts(self.start_ptr().add(offset), count) })
- }
-
- /// Performs the same functionality as [`CoherentAllocation::as_slice`], except that a mutable
- /// slice is returned.
- ///
- /// # Safety
- ///
- /// * Callers must ensure that the device does not read/write to/from memory while the returned
- /// slice is live.
- /// * Callers must ensure that this call does not race with a read or write to the same region
- /// while the returned slice is live.
- pub unsafe fn as_slice_mut(&mut self, offset: usize, count: usize) -> Result<&mut [T]> {
- self.validate_range(offset, count)?;
- // SAFETY:
- // - The pointer is valid due to type invariant on `CoherentAllocation`,
- // we've just checked that the range and index is within bounds. The immutability of the
- // data is also guaranteed by the safety requirements of the function.
- // - `offset + count` can't overflow since it is smaller than `self.count` and we've checked
- // that `self.count` won't overflow early in the constructor.
- Ok(unsafe { core::slice::from_raw_parts_mut(self.start_ptr_mut().add(offset), count) })
- }
-
- /// Writes data to the region starting from `offset`. `offset` is in units of `T`, not the
- /// number of bytes.
- ///
- /// # Safety
- ///
- /// * Callers must ensure that this call does not race with a read or write to the same region
- /// that overlaps with this write.
- ///
- /// # Examples
- ///
- /// ```
- /// # fn test(alloc: &mut kernel::dma::CoherentAllocation<u8>) -> Result {
- /// let somedata: [u8; 4] = [0xf; 4];
- /// let buf: &[u8] = &somedata;
- /// // SAFETY: There is no concurrent HW operation on the device and no other R/W access to the
- /// // region.
- /// unsafe { alloc.write(buf, 0)?; }
- /// # Ok::<(), Error>(()) }
- /// ```
- pub unsafe fn write(&mut self, src: &[T], offset: usize) -> Result {
- self.validate_range(offset, src.len())?;
- // SAFETY:
- // - The pointer is valid due to type invariant on `CoherentAllocation`
- // and we've just checked that the range and index is within bounds.
- // - `offset + count` can't overflow since it is smaller than `self.count` and we've checked
- // that `self.count` won't overflow early in the constructor.
- unsafe {
- core::ptr::copy_nonoverlapping(
- src.as_ptr(),
- self.start_ptr_mut().add(offset),
- src.len(),
- )
- };
- Ok(())
- }
-}
-
/// Note that the device configured to do DMA must be halted before this object is dropped.
impl<T: KnownSize + ?Sized> Drop for Coherent<T> {
fn drop(&mut self) {
next prev parent reply other threads:[~2026-03-21 18:22 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 19:45 [PATCH v2 0/8] dma::Coherent & dma::CoherentBox API Danilo Krummrich
2026-03-20 19:45 ` [PATCH v2 1/8] rust: dma: use "kernel vertical" style for imports Danilo Krummrich
2026-03-24 14:02 ` Andreas Hindborg
2026-03-20 19:45 ` [PATCH v2 2/8] rust: dma: add generalized container for types other than slices Danilo Krummrich
2026-03-21 23:22 ` Aditya Rajan
2026-03-22 0:47 ` Gary Guo
2026-03-22 6:24 ` Aditya Rajan
2026-03-24 13:42 ` Andreas Hindborg
2026-03-24 14:06 ` Gary Guo
2026-03-24 14:37 ` Andreas Hindborg
2026-03-20 19:45 ` [PATCH v2 3/8] rust: dma: add zeroed constructor to `Coherent` Danilo Krummrich
2026-03-21 6:37 ` Alexandre Courbot
2026-03-24 13:46 ` Andreas Hindborg
2026-03-20 19:45 ` [PATCH v2 4/8] rust: dma: introduce dma::CoherentBox for memory initialization Danilo Krummrich
2026-03-20 20:55 ` Gary Guo
2026-03-24 13:57 ` Andreas Hindborg
2026-03-20 19:45 ` [PATCH v2 5/8] rust: dma: add Coherent:init() and Coherent::init_with_attrs() Danilo Krummrich
2026-03-20 20:56 ` Gary Guo
2026-03-24 14:00 ` Andreas Hindborg
2026-03-24 15:03 ` Danilo Krummrich
2026-03-24 15:40 ` Andreas Hindborg
2026-03-20 19:45 ` [PATCH v2 6/8] gpu: nova-core: use Coherent::init to initialize GspFwWprMeta Danilo Krummrich
2026-03-20 21:04 ` Gary Guo
2026-03-20 19:45 ` [PATCH v2 7/8] gpu: nova-core: convert Gsp::new() to use CoherentBox Danilo Krummrich
2026-03-20 21:06 ` Gary Guo
2026-03-20 19:45 ` [PATCH v2 8/8] gpu: nova-core: convert to new dma::Coherent API Danilo Krummrich
2026-03-21 16:50 ` Gary Guo
2026-03-21 18:22 ` Danilo Krummrich [this message]
2026-03-21 22:36 ` Gary Guo
2026-03-21 5:13 ` [PATCH v2 0/8] dma::Coherent & dma::CoherentBox API Alexandre Courbot
2026-03-23 21:56 ` 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=DH8O47F2GM1Z.3H3E13RSKIV22@kernel.org \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=abdiel.janulgue@gmail.com \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=driver-core@lists.linux.dev \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=robin.murphy@arm.com \
--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