From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB07B28851C; Sat, 21 Mar 2026 18:22:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774117364; cv=none; b=I6HgRkWN0+pIx/JXwct2In6Ts368cNvy6hK6F9+TBzo/HVAnLgSBKygbNKqP5JOpfmNqOZfiDSpoyyvbDXFLhZOpMfvNFv6ylqaLw4CdBoGpzY7dskf2L6rcuMfNgfy/8w2JZeoD5JC8ZCtB33wzTjXDDaQNtIMQ/b/VubLHZq4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774117364; c=relaxed/simple; bh=DxozQ+XKxQ0fD6TkCuvC+HyBcPkFBTcRM0Dqohddfo0=; h=Content-Type:Date:Message-Id:Cc:To:From:Subject:MIME-Version: References:In-Reply-To; b=Lm/scWH9VWhjpuBvr7YPP3b2e1QFUsZEBWZx5gE9Y8o7qvcLBv/vfGHvKbZir2bcNnDrxX6lL4gviKeIgZFtpxvlpP+4jSR44xDzLKTeEJnw3lINo0y2sze6XlrUE0jciNKw1mIKAj8lwettLvPO+qosm0VSfgQatZdz6k3s94s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=In99FVRi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="In99FVRi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23F40C19421; Sat, 21 Mar 2026 18:22:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774117364; bh=DxozQ+XKxQ0fD6TkCuvC+HyBcPkFBTcRM0Dqohddfo0=; h=Date:Cc:To:From:Subject:References:In-Reply-To:From; b=In99FVRiLVR8JAEuAUj37ZAcjEfc/J9DLBPt7ErZAudMrz9sxPDkUu7kINQ53iphh j4Y0tIsVIqCz28Y3qLSPlKHUN9V9U2iNt8bkhYaZTx9w3ESus1B3hfYqAQmGShk83Y 2jBI11W/0fVaX3WroucaUZ7HQMTvR6a7EY0ImrGrGRmIwl67Ea0cbgWxk/0d4xl/ZH lDCTE9MEU7KNpB0SCqizoTGi8tTq1NCoerX1CNN1gWwMgeNIun78FOMf/x9iMlNOQf vXtF8z+NLhwUn8dr2eBFpXV66WQXNC8mQr5mXzK/WsIqlU+2ONFN0GAGkqJ4sdEPt1 oX2ybLE9f/J7w== Content-Type: text/plain; charset=UTF-8 Date: Sat, 21 Mar 2026 19:22:39 +0100 Message-Id: Cc: , , , , , , , , , , , , , , , To: "Gary Guo" From: "Danilo Krummrich" Subject: Re: [PATCH v2 8/8] gpu: nova-core: convert to new dma::Coherent API Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <20260320194626.36263-1-dakr@kernel.org> <20260320194626.36263-9-dakr@kernel.org> Content-Language: en-US X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; DSN=0; uuencode=0; attachmentreminder=0; deliveryformat=0 X-Identity-Key: id8 Fcc: imap://kernel%40dakr.org@imap.dakr.org/Sent In-Reply-To: Content-Transfer-Encoding: 7bit X-TUID: 9r29XOjfZmFI 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 Date: Sat Mar 21 19:18:08 2026 +0100 rust: dma: remove dma::CoherentAllocation Now that everything has been converted to the new dma::Coherent API, remove dma::CoherentAllocation. Suggested-by: Gary Guo Signed-off-by: Danilo Krummrich 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 = Coherent<[T]>; - -impl CoherentAllocation { - /// Allocates a region of `size_of:: * count` of coherent memory. - /// - /// # Examples - /// - /// ``` - /// # use kernel::device::{Bound, Device}; - /// use kernel::dma::{attrs::*, CoherentAllocation}; - /// - /// # fn test(dev: &Device) -> Result { - /// let c: CoherentAllocation = - /// CoherentAllocation::alloc_attrs(dev, 4, GFP_KERNEL, DMA_ATTR_NO_WARN)?; - /// # Ok::<(), Error>(()) } - /// ``` - pub fn alloc_attrs( - dev: &device::Device, - count: usize, - gfp_flags: kernel::alloc::Flags, - dma_attrs: Attrs, - ) -> Result> { - 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, - count: usize, - gfp_flags: kernel::alloc::Flags, - ) -> Result> { - 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 { - if offset >= self.len() { - Err(EINVAL) - } else { - Ok(self.dma_handle + (offset * core::mem::size_of::()) 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) -> 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 Drop for Coherent { fn drop(&mut self) {