| 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: <cuihp4wo5bcku75myq7mfbfvyddwptitiyy6pz5ldq2l6robxk@kghlibxpr7wf>
Date: Sun, 8 Feb 2026 00:59:10 +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-kselftest@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 6/9] PCI: dwc: ep: Report integrated eDMA resources
via EPC remote-resource API
On Fri, Feb 06, 2026 at 01:06:46PM -0500, Frank Li wrote:
> On Sat, Feb 07, 2026 at 02:26:43AM +0900, Koichiro Den wrote:
> > Implement pci_epc_ops.get_remote_resources() for DesignWare PCIe
> > endpoint controllers with integrated eDMA.
> >
> > Report:
> > - the eDMA controller MMIO window (physical base + size),
> > - each non-empty per-channel linked-list region, along with
> > per-channel metadata such as the Linux IRQ number and the
> > interrupt-emulation doorbell register offset.
> >
> > This allows endpoint function drivers (e.g. pci-epf-test) to discover
> > the eDMA resources and map a suitable doorbell target into BAR space.
> >
> > Signed-off-by: Koichiro Den <den@...inux.co.jp>
> > ---
> > .../pci/controller/dwc/pcie-designware-ep.c | 85 +++++++++++++++++++
> > 1 file changed, 85 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index 7e7844ff0f7e..29dedac86190 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -8,6 +8,7 @@
> >
> > #include <linux/align.h>
> > #include <linux/bitfield.h>
> > +#include <linux/dma/edma.h>
> > #include <linux/of.h>
> > #include <linux/platform_device.h>
> >
> > @@ -808,6 +809,89 @@ dw_pcie_ep_get_features(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
> > return ep->ops->get_features(ep);
> > }
> >
> > +static int
> > +dw_pcie_ep_get_remote_resources(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > + struct pci_epc_remote_resource *resources,
> > + int num_resources)
> > +{
> > + struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + struct dw_edma_chip *edma = &pci->edma;
> > + struct dw_edma_chan_info info;
> > + int ll_cnt = 0, needed, idx = 0;
> > + resource_size_t dma_size;
> > + phys_addr_t dma_phys;
> > + unsigned int i;
> > + int ret;
> > +
> > + if (!pci->edma_reg_size)
> > + return 0;
> > +
> > + dma_phys = pci->edma_reg_phys;
> > + dma_size = pci->edma_reg_size;
> > +
> > + for (i = 0; i < edma->ll_wr_cnt; i++)
> > + if (edma->ll_region_wr[i].sz)
> > + ll_cnt++;
> > +
> > + for (i = 0; i < edma->ll_rd_cnt; i++)
> > + if (edma->ll_region_rd[i].sz)
> > + ll_cnt++;
> > +
> > + needed = 1 + ll_cnt;
> > +
> > + /* Count query mode */
> > + if (!resources || !num_resources)
> > + return needed;
> > +
> > + if (num_resources < needed)
> > + return -ENOSPC;
> > +
> > + resources[idx++] = (struct pci_epc_remote_resource) {
> > + .type = PCI_EPC_RR_DMA_CTRL_MMIO,
> > + .phys_addr = dma_phys,
> > + .size = dma_size,
> > + };
> > +
> > + /* One LL region per write channel */
> > + for (i = 0; i < edma->ll_wr_cnt; i++) {
> > + if (!edma->ll_region_wr[i].sz)
> > + continue;
> > +
> > + ret = dw_edma_chan_info(edma, i, &info);
> > + if (ret)
> > + return ret;
> > +
> > + resources[idx++] = (struct pci_epc_remote_resource) {
> > + .type = PCI_EPC_RR_DMA_CHAN_DESC,
> > + .phys_addr = edma->ll_region_wr[i].paddr,
> > + .size = edma->ll_region_wr[i].sz,
> > + .u.dma_chan_desc.irq = info.irq,
> > + .u.dma_chan_desc.db_offset = info.db_offset,
> > + };
> > + }
> > +
> > + /* One LL region per read channel */
> > + for (i = 0; i < edma->ll_rd_cnt; i++) {
> > + if (!edma->ll_region_rd[i].sz)
> > + continue;
> > +
> > + ret = dw_edma_chan_info(edma, i + edma->ll_wr_cnt, &info);
>
> edma's information is what dw-EP pass to edma driver, supposed dw-ep know
> irq and HDMI or EDMA's information, I think needn't go around to EDMA again
> to fetch this information back.
Thanks for the feedback. As I understand it, yes, dw-EP passes information
such as nr_irqs/ll_wr_cnt/ll_rd_cnt to dw-edma, but the per-channel
chan-to-irq mapping is decided inside dw-edma. The doorbell offset is also
derived from the dw-(e|h)dma v0 core registers.
To avoid having dw-EP call back into dw-edma just to fetch the mapping
(i.e. get rid of dw_edma_chan_info()), we could cache the per-channel
metadata in struct dw_edma_chip and have dw-edma fill it at probe time.
Then get_remote_resources() can just read the cached values.
Something like:
diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h
index 53b31a974331..83503aacaf5f 100644
--- a/include/linux/dma/edma.h
+++ b/include/linux/dma/edma.h
@@ -88,6 +88,17 @@ struct dw_edma_peripheral_config {
enum dw_edma_ch_irq_mode irq_mode;
};
+/**
+ * struct dw_edma_ch_info - DW eDMA channel metadata
+ * @irq: Linux IRQ number used by this channel's interrupt vector
+ * @db_offset: offset within the eDMA register window that can be used as
+ * an interrupt-emulation doorbell for this channel
+ */
+struct dw_edma_ch_info {
+ int irq;
+ resource_size_t db_offset;
+};
+
/**
* struct dw_edma_chip - representation of DesignWare eDMA controller hardware
* @dev: struct device of the eDMA controller
@@ -124,6 +135,10 @@ struct dw_edma_chip {
struct dw_edma_region dt_region_wr[EDMA_MAX_WR_CH];
struct dw_edma_region dt_region_rd[EDMA_MAX_RD_CH];
+ /* cached channel info */
+ struct dw_edma_ch_info ch_info_wr[EDMA_MAX_WR_CH];
+ struct dw_edma_ch_info ch_info_rd[EDMA_MAX_RD_CH];
+
enum dw_edma_map_format mf;
struct dw_edma *dw;
Best regards,
Koichiro
>
> Frank
> > + if (ret)
> > + return ret;
> > +
> > + resources[idx++] = (struct pci_epc_remote_resource) {
> > + .type = PCI_EPC_RR_DMA_CHAN_DESC,
> > + .phys_addr = edma->ll_region_rd[i].paddr,
> > + .size = edma->ll_region_rd[i].sz,
> > + .u.dma_chan_desc.irq = info.irq,
> > + .u.dma_chan_desc.db_offset = info.db_offset,
> > + };
> > + }
> > +
> > + return idx;
> > +}
> > +
> > static const struct pci_epc_ops epc_ops = {
> > .write_header = dw_pcie_ep_write_header,
> > .set_bar = dw_pcie_ep_set_bar,
> > @@ -823,6 +907,7 @@ static const struct pci_epc_ops epc_ops = {
> > .start = dw_pcie_ep_start,
> > .stop = dw_pcie_ep_stop,
> > .get_features = dw_pcie_ep_get_features,
> > + .get_remote_resources = dw_pcie_ep_get_remote_resources,
> > };
> >
> > /**
> > --
> > 2.51.0
> >
Powered by blists - more mailing lists