On Wed, Feb 04, 2026 at 02:13:54PM +0200, Leon Romanovsky wrote: > On Wed, Feb 04, 2026 at 01:01:54PM +0100, Maxime Ripard wrote: > > On Wed, Feb 04, 2026 at 01:52:12PM +0200, Leon Romanovsky wrote: > > > On Wed, Feb 04, 2026 at 09:56:08AM +0100, Maxime Ripard wrote: > > > > On Wed, Feb 04, 2026 at 10:16:30AM +0200, Leon Romanovsky wrote: > > > > > On Mon, Feb 02, 2026 at 06:04:25PM +0200, Leon Romanovsky wrote: > > > > > > On Sat, Jan 31, 2026 at 07:34:10AM +0200, Leon Romanovsky wrote: > > > > > > > Changelog: > > > > > > > v7: > > > > > > > > > > > > <...> > > > > > > > > > > > > > Leon Romanovsky (8): > > > > > > > dma-buf: Rename .move_notify() callback to a clearer > > > > > > > identifier > > > > > > > dma-buf: Rename dma_buf_move_notify() to > > > > > > > dma_buf_invalidate_mappings() > > > > > > > dma-buf: Always build with DMABUF_MOVE_NOTIFY > > > > > > > vfio: Wait for dma-buf invalidation to complete > > > > > > > dma-buf: Make .invalidate_mapping() truly optional > > > > > > > dma-buf: Add dma_buf_attach_revocable() > > > > > > > vfio: Permit VFIO to work with pinned importers > > > > > > > iommufd: Add dma_buf_pin() > > > > > > > > > > > > > > drivers/dma-buf/Kconfig | 12 ----- > > > > > > > drivers/dma-buf/dma-buf.c | 69 > > > > > > > ++++++++++++++++++++----- > > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 14 ++--- > > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- > > > > > > > drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +- > > > > > > > drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +- > > > > > > > drivers/gpu/drm/xe/tests/xe_dma_buf.c | 7 ++- > > > > > > > drivers/gpu/drm/xe/xe_bo.c | 2 +- > > > > > > > drivers/gpu/drm/xe/xe_dma_buf.c | 14 ++--- > > > > > > > drivers/infiniband/core/umem_dmabuf.c | 13 ----- > > > > > > > drivers/infiniband/hw/mlx5/mr.c | 2 +- > > > > > > > drivers/iommu/iommufd/pages.c | 11 +++- > > > > > > > drivers/iommu/iommufd/selftest.c | 2 +- > > > > > > > drivers/vfio/pci/vfio_pci_dmabuf.c | 80 > > > > > > > ++++++++++++++++++++++------- > > > > > > > include/linux/dma-buf.h | 17 +++--- > > > > > > > 15 files changed, 153 insertions(+), 96 deletions(-) > > > > > > > > > > > > Christian, > > > > > > > > > > > > Given the ongoing discussion around patch v5, I'm a bit unclear on > > > > > > the > > > > > > current state. Is the series ready for merging, or do you need me to > > > > > > rework anything further? > > > > > > > > > > Christian, > > > > > > > > > > Let's not miss the merge window for work that is already ready. > > > > > > > > The cutoff date for the merge window was on 25/1, so it was already > > > > missed by the time you sent your series. > > > > > > The primary goal of this series is to update dma-buf. The changes in > > > drivers/gpu/drm are limited to straightforward renames. > > > > And yet, dma-buf is maintained through drm. > > > > Also, it's a general rule Linus has, it's nothing specific to DRM. > > Can you point me to that general rule? > > From what I have seen, subsystems such as netdev, the block layer, and RDMA > continue > to accept code that is ready for merging, especially when it has been > thoroughly > reviewed by multiple maintainers across different subsystems.
He said it multiple times, but here's one of such examples: https://lore.kernel.org/all/CA+55aFwdd30eBsnMLB=ncExY0-P=easxkn_o6ir10juyvsy...@mail.gmail.com/ And quoting: > In particular, if you cannot follow the simple merge window rules > (this whole two-week merge window and linux-next process has been in > place over a decade), at least make the end result look good. Make it > all look easy and problem-free. > > [...] > > Next merge window I will not accept anything even remotely like that. > Things that haven't been in linux-next will be rejected So, yeah, we can make exceptions. But you should ask and justify for one, instead of expecting us to pick up a patch submission that was already late. Maxime
signature.asc
Description: PGP signature
