Re: [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function

On Thu, Aug 13, 2026 at 11:15:31PM +0900, Koichiro Den wrote:
> On Thu, Aug 13, 2026 at 02:50:59PM +0200, Manivannan Sadhasivam wrote:
> > On Thu, Aug 13, 2026 at 01:46:07PM +0200, Niklas Cassel wrote:
> > > Hello Koichiro,
> > >
> > > On Thu, Aug 13, 2026 at 03:37:47PM +0900, Koichiro Den wrote:
> > > > This is v7, the remaining patch set for PCI endpoint DMA.
> > > > Parts 2 and 3 were merged per Frank's suggestion.
> > >
> > > (snip)
> > >
> > > > One open question is how to support endpoint controllers with only one
> > > > PF. Keeping DMA in a separate EPF requires multi-function endpoint
> > > > support. Folding it into vNTB would work on single-function
> > > > controllers, but would also couple the two implementations. This series
> > > > keeps the separate EPF model.
> > >
> > > I see all the work you are putting in and I admire the effort.
> > >
> > > This is now v7. I think it is time that we close the open question by
> > > waiting for a reply from the PCI endpoint maintainers' opinion on the
> > > design before continuing. (I am not a PCI endpoint maintainer.)
> > >
> > > I understand that you want a common DMA abstraction, that can represent
> > > different (embedded) DMA controllers on the endpoint side.
> > >
> > > But if vNTB is the only consumer of this, then why not simply embed this
> > > DMA abstraction in some BAR exposed by the vNTB EPF?
> > >
> > > Looking at the host side driver that goes with the (v)NTB driver:
> > > drivers/ntb/hw/epf/ntb_hw_epf.c
> > >
> > > The BAR layouts are hard coded, and it only supports three different
> > > layouts. Would it not be possible to add a fourth layout that has the
> > > DMA abstraction somewhere in one of the BARs? ('BAR_DMA' ?)
> > >
> > >
> > > Right now, I wonder if it is not a bit premature optimization to create a
> > > DMA EPF, if vNTB will be the only (ever?) user.
> > >
> >
> > Yeah, I feel the same. I haven't seen an usecase to program the DMA controller
> > from the host outside of vNTB. This feature is supported mostly because it
> > exists in hardware and someone wants to tick the checkbox.
> >
> > Though, I'm not against doing it within vNTB as Niklas suggested, but
> > generalising it in the form of a new EPF driver just for the sake of a single
> > driver sounds like an overkill and maintenance burden.
> >
> > Sorry for saying this in v7. I've been meaning to say it, but somehow ended up
> > procrastinating too much.
>
> No bother. Since Frank has given a lot of feedback on this series, I'd also like
> to hear his view.
>
> I'm fine with either direction, and can revisit the earlier vNTB-embedded
> approach:
> https://lore.kernel.org/r/sn67hi7kljh7cgmgodatb3naz2astlaklqfobdbxyyzgoohxqb@4nnetbhqwba4/

One of the important value is test dw-edma-pcie.c, which generally depend
on some fpga hardware. If there are epf driver work as fpga hardware, it
will help cover edma remote user case. So more user can test it.

Of course, this implement are over complex. I suggest update dma-engine
chan_id to support static allocate, which also need be fixed because
some drivers have such dependence, anyway need be fixed. After this fix,
this patches will become simpler.

VNTB case, it'd better put such informaiton into one BARs and work on
single-function.

I suggest split two things

1 - create simple epf driver to test dw-edma-pcie.c.
2 - vntb support DMA.

of course, if shared efforts, it will be great.

Frank

>
> Best regards,
> Koichiro
>
> >
> > - Mani
> >
> > --
> > மணிவண்ணன் சதாசிவம்