Re: [PATCH v2 0/3] iio: buffer: Fix DMABUF mapping in some systems

[Jonathan Cameron <jic23@kernel.org>]

On Tue, 07 Oct 2025 09:25:19 +0100
Nuno Sá <noname.nuno@gmail.com> wrote:

> On Mon, 2025-10-06 at 11:44 -0500, David Lechner wrote:
> > On 10/6/25 11:25 AM, Nuno Sá wrote:  
> > > On Mon, 2025-10-06 at 11:18 -0500, David Lechner wrote:  
> > > > On 10/6/25 11:06 AM, Nuno Sá via B4 Relay wrote:  
> > > > > This series fixes an issue with DMABUF support in the IIO subsystem
> > > > > where
> > > > > the wrong DMA device could be used for buffer mapping operations. This
> > > > > becomes critical on systems like Xilinx/AMD ZynqMP Ultrascale where
> > > > > memory
> > > > > can be mapped above the 32-bit address range.
> > > > > 
> > > > > Problem:
> > > > > --------
> > > > > The current IIO DMABUF implementation assumes it can use the parent
> > > > > device
> > > > > of the IIO device for DMA operations. However, this device may not have
> > > > > the appropriate DMA mask configuration for accessing high memory
> > > > > addresses.
> > > > > On systems where memory is mapped above 32-bits, this leads to the use
> > > > > of
> > > > > bounce buffers through swiotlb, significantly impacting performance.
> > > > > 
> > > > > Solution:
> > > > > ---------
> > > > > This series introduces a new .get_dma_dev() callback in the buffer
> > > > > access
> > > > > functions that allows buffer implementations to specify the correct DMA
> > > > > device that should be used for DMABUF operations. The DMA buffer
> > > > > infrastructure implements this callback to return the device that
> > > > > actually
> > > > > owns the DMA channel, ensuring proper memory mapping without bounce
> > > > > buffers.
> > > > > 
> > > > > Changes:
> > > > > --------
> > > > > 1. Add .get_dma_dev() callback to iio_buffer_access_funcs and update
> > > > > core
> > > > >    DMABUF code to use it when available
> > > > > 2. Implement the callback in the DMA buffer infrastructure
> > > > > 3. Wire up the callback in the dmaengine buffer implementation
> > > > > 
> > > > > This ensures that DMABUF operations use the device with the correct DMA
> > > > > configuration, eliminating unnecessary bounce buffer usage and improving
> > > > > performance on high-memory systems.
> > > > > 
> > > > > (AI generated cover. I would not be this formal but I guess is not
> > > > > that bad :))
> > > > > 
> > > > > ---
> > > > > Changes in v2:
> > > > > - Dropped Fixes tags on the first two patches and Cc stable them instead
> > > > >   (as prerequisites for the third patch). 
> > > > > - Link to v1:
> > > > > https://lore.kernel.org/r/20251002-fix-iio-dmabuf-get-dma-device-v1-0-c1c9945029d0@analog.com  
> > > > 
> > > > Did you not care for my other suggestions in v1?  
> > > 
> > > Completely missed them, sorry! I kind of stop reading in the stable stuff.

On that 'stable' stuff I'm very unclear on the logic for +CC a dependency to
stable@vger.kernel.org  

The +CC is IIUC the thing that gets a patch queued rather than the fixes
tag and if you don't provide a fixes tag assumption is that it goes back as far
as it can be applied.   That concerns me as they could therefore get pushed
back further than the thing dependent on them.
Ah well. I guess they do some magic stuff on series though as the
stable-rules.rst calls out the case you have here.

So applied as is but I marked the final patch for stable. Would have have
been a weird situation if I decided not to do that for some reason.

Applied to the fixes-togreg branch of iio.git.  That has a weird mid merge window
base at the moment so I'll rebase on rc1 once available and push out at that point.

Jonathan



> > > I'm
> > > ok with the helper function. For the clarification I feel it's redundant.
> > > The  
> > 
> > I was thinking extra clarification could be helpful for someone new to the IIO
> > subsystem. But it would be quite rare to add a new buffer implementation
> > anyway.
> > So probably not too many people would actually ever read it. :-)  
> 
> I mean, it does not harm. If you want to add it, I'll hack it (as I feel it
> should be a separate patch also covering the other .ops related to DMA buffers).
> 
> >   
> > > field is called .get_dma_dev() and the description "called to get the DMA
> > > channel associated with this buffer" already implies is for DMA buffer. Same
> > > as
> > > ops like .enqueue_dmabuf().
> > > 
> > > - Nuno Sá  
> > 
> > I don't feel too strongly about either change, so either way,
> > 
> > Reviewed-by: David Lechner <dlechner@baylibre.com>
> >   
> 
> Thx!
> 
> - Nuno Sá