On Mon, Aug 26, 2024 at 03:27:30PM +, Michael Kelley wrote:
> OK, this makes sense to me. The DMA_ATTR_* symbols are currently
> defined as just values that are not part of an enum or any other higher
> level abstraction, and the "attrs" parameter to the dma_* functions is
> just "unsigned long
On Thu, Aug 22, 2024 at 11:37:11AM -0700, mhkelle...@gmail.com wrote:
> Because it's not possible to detect at runtime whether a DMA map call
> is made in a context that can block, the calls in key device drivers
> must be updated with a MAY_BLOCK attribute, if appropriate. When this
> attribute is
On Thu, Nov 23, 2023 at 12:24:49AM +, Michael Kelley wrote:
> > I really do not want to expose vmap_pages_range. Please try to come up
> > with a good way to encapsulate your map at a certain address primitive
> > and implement it in vmalloc.c.
>
> To clarify, is your concern narrowly about v
On Tue, Nov 21, 2023 at 01:20:11PM -0800, mhkelle...@gmail.com wrote:
> From: Michael Kelley
>
> The mm subsystem currently provides no mechanism to map memory pages
> to a specified virtual address range. A virtual address range can be
> allocated using get_vm_area(), but the only function avai
eed to check it and remove the iommu parameter everywhere.
Yes, that's much better than exposing the iommu ops to a place that
should not care about them:
Acked-by: Christoph Hellwig
