| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <dmbz4qealzaiqvmmb4fcvsnkymmcm4qoxn5lsp2h4jal4cpmsv@hdfyd7evbr74>
Date: Thu, 5 Feb 2026 15:53:52 +0900
From: Koichiro Den <den@...inux.co.jp>
To: Frank Li <Frank.li@....com>
Cc: vkoul@...nel.org, mani@...nel.org, jingoohan1@...il.com,
lpieralisi@...nel.org, kwilczynski@...nel.org, robh@...nel.org, bhelgaas@...gle.com,
dmaengine@...r.kernel.org, linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 06/11] PCI: endpoint: Add remote resource query API
On Wed, Feb 04, 2026 at 12:55:58PM -0500, Frank Li wrote:
> On Wed, Feb 04, 2026 at 11:54:34PM +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 <den@...inux.co.jp>
> > ---
> > 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
> > + * @epc: EPC device
> > + * @func_no: function number
> > + * @vfunc_no: virtual function number
> > + * @resources: output array (may be NULL to query required count)
> > + * @num_resources: size of @resources array in entries (0 when querying count)
> > + *
> > + * 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 the backend for such resources.
> > + *
> > + * Return:
> > + * * >= 0: number of resources returned (or required, if @resources is NULL)
> > + * * -EOPNOTSUPP: backend does not support remote resource queries
> > + * * other -errno on failure
> > + */
> > +int pci_epc_get_remote_resources(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > + struct pci_epc_remote_resource *resources,
> > + int num_resources)
> > +{
> > + int ret;
> > +
> > + if (!epc || !epc->ops)
> > + return -EINVAL;
> > +
> > + if (func_no >= epc->max_functions)
> > + return -EINVAL;
> > +
> > + if (!epc->ops->get_remote_resources)
> > + return -EOPNOTSUPP;
> > +
> > + mutex_lock(&epc->lock);
> > + ret = epc->ops->get_remote_resources(epc, func_no, vfunc_no,
> > + resources, num_resources);
> > + mutex_unlock(&epc->lock);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(pci_epc_get_remote_resources);
> > +
> > /**
> > * pci_epc_stop() - stop the PCI link
> > * @epc: the link of the EPC device that has to be stopped
> > diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> > index c021c7af175f..af60d4ad2f0e 100644
> > --- a/include/linux/pci-epc.h
> > +++ b/include/linux/pci-epc.h
> > @@ -61,6 +61,44 @@ struct pci_epc_map {
> > void __iomem *virt_addr;
> > };
> >
> > +/**
> > + * enum pci_epc_remote_resource_type - remote resource type identifiers
> > + * @PCI_EPC_RR_DMA_CTRL_MMIO: Integrated DMA controller register window (MMIO)
> > + * @PCI_EPC_RR_DMA_CHAN_DESC: Per-channel DMA descriptor
> > + *
> > + * EPC backends may expose auxiliary blocks (e.g. DMA engines) by mapping their
> > + * register windows and descriptor memories into BAR space. This enum
> > + * identifies the type of each exposable resource.
> > + */
> > +enum pci_epc_remote_resource_type {
> > + PCI_EPC_RR_DMA_CTRL_MMIO,
> > + PCI_EPC_RR_DMA_CHAN_DESC,
> > +};
> > +
> > +/**
> > + * struct pci_epc_remote_resource - a physical resource that can be exposed
> > + * @type: resource type, see enum pci_epc_remote_resource_type
> > + * @phys_addr: physical base address of the resource
> > + * @size: size of the resource in bytes
> > + * @u: type-specific metadata
> > + *
> > + * For @PCI_EPC_RR_DMA_CHAN_DESC, @u.dma_chan_desc provides per-channel
> > + * information.
> > + */
> > +struct pci_epc_remote_resource {
> > + enum pci_epc_remote_resource_type type;
> > + phys_addr_t phys_addr;
> > + resource_size_t size;
>
> is it good use struct resource?
Personally I don't think it's the best fit here, since these remote
resources are not meant to participate in the global resource tree or
managed by the resource management framework. And most of struct resource
fields (name/flags and the links) does not make sense in this context.
>
> > +
> > + union {
> > + /* PCI_EPC_RR_DMA_CHAN_DESC */
> > + struct {
> > + u16 hw_chan_id;
> > + bool ep2rc;
> > + } dma_chan_desc;
> > + } u;
> > +};
> > +
> > /**
> > * struct pci_epc_ops - set of function pointers for performing EPC operations
> > * @write_header: ops to populate configuration space header
> > @@ -84,6 +122,8 @@ struct pci_epc_map {
> > * @start: ops to start the PCI link
> > * @stop: ops to stop the PCI link
> > * @get_features: ops to get the features supported by the EPC
> > + * @get_remote_resources: ops to retrieve controller-owned resources that can be
> > + * exposed to the remote host (optional)
>
> Add comments, must set 'type' of pci_epc_remote_resource.
Would something like the following address your concern?
* @get_remote_resources: ops to retrieve controller-owned resources that can be
* exposed to the remote host (optional)
+ * The callback fills @resources (up to @num_resources entries)
+ * and returns the number of valid entries. Each returned entry
+ * must have @type set (which selects the valid union member in @u)
+ * and provide valid @phys_addr/@...e.
Thanks for the review,
Koichiro
>
> Over all it is good.
>
> Frank
> > * @owner: the module owner containing the ops
> > */
> > struct pci_epc_ops {
> > @@ -115,6 +155,9 @@ struct pci_epc_ops {
> > void (*stop)(struct pci_epc *epc);
> > const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
> > u8 func_no, u8 vfunc_no);
> > + int (*get_remote_resources)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > + struct pci_epc_remote_resource *resources,
> > + int num_resources);
> > struct module *owner;
> > };
> >
> > @@ -309,6 +352,9 @@ int pci_epc_start(struct pci_epc *epc);
> > void pci_epc_stop(struct pci_epc *epc);
> > const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
> > u8 func_no, u8 vfunc_no);
> > +int pci_epc_get_remote_resources(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > + struct pci_epc_remote_resource *resources,
> > + int num_resources);
> > enum pci_barno
> > pci_epc_get_first_free_bar(const struct pci_epc_features *epc_features);
> > enum pci_barno pci_epc_get_next_free_bar(const struct pci_epc_features
> > --
> > 2.51.0
> >
Powered by blists - more mailing lists