<!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> Am 15.04.25 um 15:10 schrieb Simona Vetter: <blockquote type="cite" cite="mid:Z_5a3ckZiY-fINNW@phenom.ffwll.local"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">This is for devices who only want to do a vmap of the buffer, isn't it? </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> ... it's for the vmap only case, where you might not even have a struct device. Or definitely not a reasonable one, like maybe a faux_bus device or some device on a bus that really doesn't do dma (e.g. spi or i2c), and where hence dma_buf_map_attachment is just something you never ever want to do.</pre> </blockquote> Even in that case I would still suggest to at least create an attachment to let the exporter know that somebody is doing something with it's buffer. That is also important for move notification since you can't do those without an attachment. BTW: What is keeping a vmap alive after dropping the reservation lock? There is no pinning whatsoever as far as I can see. <blockquote type="cite" cite="mid:Z_5a3ckZiY-fINNW@phenom.ffwll.local"> <pre class="moz-quote-pre" wrap="">I think we might want to transform obj->import_attach into a union or tagged pointer or something like that, which can cover both cases. And maybe a drm_gem_bo_imported_dma_buf() helper that gives you the dma_buf no matter what if it's imported, or NULL if it's allocated on that drm_device?</pre> </blockquote> Yeah, I had the same idea before as well. Just didn't know if that was something worth looking into. Regards, Christian. <blockquote type="cite" cite="mid:Z_5a3ckZiY-fINNW@phenom.ffwll.local"> <pre class="moz-quote-pre" wrap=""> Cheers, Sima </pre> </blockquote> </body> </html>