[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d37ccb03-0d03-46ff-b62f-2fcb78263fe7@samsung.com>
Date: Mon, 28 Apr 2025 17:33:35 +0200
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Christoph Hellwig <hch@....de>, Ian Abbott <abbotti@....co.uk>
Cc: linux-kernel@...r.kernel.org, Greg Kroah-Hartman
<gregkh@...uxfoundation.org>, H Hartley Sweeten
<hsweeten@...ionengravers.com>, Robin Murphy <robin.murphy@....com>,
iommu@...ts.linux.dev
Subject: Re: [PATCH 4/4] comedi: allocate DMA coherent buffer as individual
pages
On 28.04.2025 14:56, Christoph Hellwig wrote:
> On Tue, Apr 15, 2025 at 12:35:59PM +0100, Ian Abbott wrote:
>> + vma->vm_start = start;
>> + vma->vm_end = start + PAGE_SIZE;
>> + retval = dma_mmap_coherent(bm->dma_hw_dev, vma,
>> + buf->virt_addr,
>> + buf->dma_addr, PAGE_SIZE);
> I'm not fan of the vm_start/vm_end manipulation, but I've seen it in
> other places. In a perfect world we'd have a dma_mmap_coherent_offset
> or similar helper that encapsulates it, and then maybe later replace
> that hack with passing on the offset.
Indeed the dma_mmap_*() makes too many assumptions about the vma. The
case You mentioned is probably in drivers/infiniband/hw/hfi1/file_ops.c
but I also see that the vma->vm_pgoff is being adjusted before most
dma_mmap_*() calls, which proves that the current API is somehow
limited. It would be great to fix this too while touching the
dma_mmap_attrs() API.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Powered by blists - more mailing lists