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...
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