Re: [PATCH v12 1/7] PCI: endpoint: Add auxiliary resource query API

[Frank Li <Frank.li@nxp.com>]

On Tue, Mar 31, 2026 at 10:56:34PM +0900, Koichiro Den wrote:
> On Fri, Mar 27, 2026 at 12:31:09PM -0400, Frank Li wrote:
> > On Fri, Mar 27, 2026 at 12:54:16PM +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_count_aux_resources() / pci_epc_get_aux_resources() and the
> > > corresponding pci_epc_ops callbacks. The count helper returns the number
> > > of available resources via an output parameter, while the get helper
> > > fills a caller-provided array of resources described by type, physical
> > > address and size, plus type-specific metadata.
> > >
> > > Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
> > > Signed-off-by: Koichiro Den <den@valinux.co.jp>
> > > ---
> > > Changes in v12:
> > >   - Add pci_epc_count_aux_resources() and pci_epc_ops.count_aux_resources
> > >   - Use pci_epc_function_is_valid() instead of open-coding
> > >
> > >  drivers/pci/endpoint/pci-epc-core.c | 83 +++++++++++++++++++++++++++++
> > >  include/linux/pci-epc.h             | 53 ++++++++++++++++++
> > >  2 files changed, 136 insertions(+)
> > >
> > > diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> > > index 6c3c58185fc5..fded71a19d71 100644
> > > --- a/drivers/pci/endpoint/pci-epc-core.c
> > > +++ b/drivers/pci/endpoint/pci-epc-core.c
> > > @@ -156,6 +156,89 @@ const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
> > >  }
> > >  EXPORT_SYMBOL_GPL(pci_epc_get_features);
> > >
> > > +/**
> > > + * pci_epc_count_aux_resources() - count EPC-provided auxiliary resources
> > > + * @epc: EPC device
> > > + * @func_no: function number
> > > + * @vfunc_no: virtual function number
> > > + * @num_resources: returned number of auxiliary resources
> > > + *
> > > + * Some EPC backends integrate auxiliary blocks (e.g. DMA engines) whose control
> > > + * registers and/or descriptor memories can be exposed to the host by mapping
> > > + * them into BAR space. This helper queries how many such resources the backend
> > > + * provides.
> > > + *
> > > + * Return: 0 on success, -EOPNOTSUPP if the backend does not support auxiliary
> > > + * resource queries, or another -errno on failure.
> > > + */
> > > +int pci_epc_count_aux_resources(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > > +				int *num_resources)
> >
> > Most like such kinds APIs return count directly,
> >   < 0,  means error.
> >  >= 0,  means how many resource.
>
> I chose to return 0 on success here based on Mani's earlier feedback on v11:
> https://lore.kernel.org/linux-pci/lfbv6sjevz4xtjr6zt2hl3wap3bfwkvigqb6fdztqmutxgcvld@3t4x5gstr4nj/

I am okay for both, But may request Mani think 2nd. Most existing kernel
API use return value for count of resource.

Frank
>
> I don't have a strong preference here, but since there seems to be no clear
> policy/convention across the kernel, I would prefer to follow what is most
> consistent and maintainable for the maintainers. Of course, I'm happy to switch
> and respin if preferred.
>
> Thanks for reviewing,
> Koichiro
>
> >
> > Frank