Re: [PATCH v12 1/7] PCI: endpoint: Add auxiliary resource query API
Frank Li <[email protected]> Tue, 31 Mar 2026 10:09:28 -0400
| Newsgroups | dev.linux.lists.ntb,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci |
|---|---|
| Message-ID | <acvVmM-nk73ntNj5@lizhi-Precision-Tower-5810> |
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 <[email protected]> > > > Signed-off-by: Koichiro Den <[email protected]> > > > --- > > > 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