On Sun, Feb 08, 2026 at 01:39:40AM +0900, Koichiro Den wrote:
> On Fri, Feb 06, 2026 at 01:01:33PM -0500, Frank Li wrote:
> > On Sat, Feb 07, 2026 at 02:26:41AM +0900, Koichiro Den wrote:
> > > Endpoint controller drivers may integrate auxiliary blocks (e.g. DMA
> > > engines) whose register windows and descriptor memories metadata need to
> > > be exposed to a remote peer. Endpoint function drivers need a generic
> > > way to discover such resources without hard-coding controller-specific
> > > helpers.
> > >
> > > Add pci_epc_get_remote_resources() and the corresponding pci_epc_ops
> > > get_remote_resources() callback. The API returns a list of resources
> > > described by type, physical address and size, plus type-specific
> > > metadata.
> > >
> > > Passing resources == NULL (or num_resources == 0) returns the required
> > > number of entries.
> > >
> > > Signed-off-by: Koichiro Den <[email protected]>
> > > ---
> > > drivers/pci/endpoint/pci-epc-core.c | 41 +++++++++++++++++++++++++
> > > include/linux/pci-epc.h | 46 +++++++++++++++++++++++++++++
> > > 2 files changed, 87 insertions(+)
> > >
> > > diff --git a/drivers/pci/endpoint/pci-epc-core.c
> > > b/drivers/pci/endpoint/pci-epc-core.c
> > > index 068155819c57..fa161113e24c 100644
> > > --- a/drivers/pci/endpoint/pci-epc-core.c
> > > +++ b/drivers/pci/endpoint/pci-epc-core.c
> > > @@ -155,6 +155,47 @@ const struct pci_epc_features
> > > *pci_epc_get_features(struct pci_epc *epc,
> > > }
> > > EXPORT_SYMBOL_GPL(pci_epc_get_features);
> > >
> > > +/**
> > > + * pci_epc_get_remote_resources() - query EPC-provided remote resources
> >
> > I am not sure if it good naming, pci_epc_get_additional_resources().
> > Niklas Cassel may have good suggest, I just find you forget cc him.
>
> That's true, I just naively followed the get_maintainers.pl output.
>
> Niklas, I'd be happy to hear your thoughts on the naming here.
> One other option I had in mind after Frank's feedback is
> pci_epc_get_aux_resources().
Name looks good to me, but I think the cover-letter can be improved a lot.
(Even when looking at the cover-letter in V6.)
It seems like in v6, the main motivation is basically what is described in
PATCH v6 8/8.
On platforms where such an MSI irq domain is
not available, EPF drivers cannot provide doorbells to the RC. Even if
it's available and MSI device domain successfully created, the write
into the message address via BAR inbound mapping might not work for
platform-specific reasons (e.g. write into GITS_TRANSLATOR via iATU IB
mapping does not reach ITS at least on R-Car Gen4 Spider).
I think the first sentence in the cover-letter should be that this series,
for SoCs that cannot use GIC ITS, provides an alternate doorbell using DWC
eDMA.
So first describe the problem, then describe how you solve it.
Perhaps also show some performance numbers. E.g. vntb, you can show the
latency of ping against the ntb netdev, see e.g. the commit message for:
dc693d606644 ("PCI: endpoint: pci-epf-vntb: Add MSI doorbell support")
(I.e. compare R-Car Spider with no doorbell vs eDMA doorbell when doing
ping against the ntb netdev.)
Kind regards,
Niklas
