On Tue, Sep 29, 2026 at 11:34:05AM +0200, Christian König wrote:
> On 9/28/26 13:19, Leon Romanovsky wrote:
> > From: Leon Romanovsky <[email protected]>
> >
> > Exporters keep the &struct p2pdma_provider backing a buffer in their own
> > private data. An importer cannot reach it, so it has no way to learn how
> > its own peer-to-peer traffic would be routed before it programs its
> > hardware.
> >
> > Add an optional @p2pdma_provider callback for an exporter to hand that
> > provider out, and dma_buf_p2pdma_map_type() for an importer to ask by TLP
> > class. Exporters keep the provider where it already lives, so this adds an
> > operation rather than changing any existing signature or structure.
> >
> > Tested-by: Tushar Dave <[email protected]>
> > Signed-off-by: Leon Romanovsky <[email protected]>
> > ---
> > drivers/dma-buf/dma-buf-mapping.c | 39
> > +++++++++++++++++++++++++++++++++++++++
> > include/linux/dma-buf-mapping.h | 3 +++
> > include/linux/dma-buf.h | 19 +++++++++++++++++++
> > 3 files changed, 61 insertions(+)
<...>
> > +enum pci_p2pdma_map_type
> > +dma_buf_p2pdma_map_type(struct dma_buf_attachment *attach,
> > + unsigned int tlp_flags)
> > +{
> > + struct dma_buf *dmabuf = attach->dmabuf;
> > + struct p2pdma_provider *provider;
> > +
> > + dma_resv_assert_held(dmabuf->resv);
> > +
> > + if (!dmabuf->ops->p2pdma_provider)
> > + return PCI_P2PDMA_MAP_NONE;
> > +
> > + provider = dmabuf->ops->p2pdma_provider(dmabuf);
> > + if (!provider)
> > + return PCI_P2PDMA_MAP_NONE;
> > +
>
>
> > + return pci_p2pdma_map_type_tlp(provider, attach->dev, tlp_flags);
>
> This function call here *must* be in the exporter and not the DMA-buf
> framework.
>
> So clear NAK to putting that here.
"Look, it is easy to complain you don't like how it looks, but this
stuff is hard there are lots of competing concerns, if you have a
better idea now is a good time to present it."
https://lore.kernel.org/all/[email protected]/#t
Do you have a viable solution?
Thanks
>
> Regards,
> Christian.
