* [PATCH v7 01/10] dmaengine: Allow drivers to assign static channel IDs
2026-08-13 6:37 [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Koichiro Den
@ 2026-08-13 6:37 ` Koichiro Den
2026-08-13 6:51 ` sashiko-bot
2026-08-13 6:37 ` [PATCH v7 02/10] PCI: endpoint: Define endpoint DMA BAR metadata format Koichiro Den
` (9 subsequent siblings)
10 siblings, 1 reply; 25+ messages in thread
From: Koichiro Den @ 2026-08-13 6:37 UTC (permalink / raw)
To: Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Frank Li, Bjorn Helgaas, Jonathan Corbet,
Shuah Khan, Randy Dunlap, Vinod Koul, Jingoo Han,
Lorenzo Pieralisi, Rob Herring, Niklas Cassel, Damien Le Moal,
Arnd Bergmann
Cc: Marek Vasut, Yoshihiro Shimoda, linux-pci, linux-doc,
linux-kernel, dmaengine
The dmaengine core assigns channel IDs in registration order. If a driver
skips a hardware channel, chan_id can differ from the hardware numbering
and a client cannot reliably correlate a requested channel with hardware
resources.
Let a driver request an exact channel ID before device registration.
Reserve static IDs through the existing IDA so they remain unique, while
retaining automatic IDA allocation as the default.
Use direction-flattened IDs for dw-edma channels. Unlike the
direction-local hardware channel number, these IDs are unique within the
DMA device.
Suggested-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
Changes in v7:
- New patch. (Frank)
https://lore.kernel.org/r/lm7tadnxsyrypu4mypptlkx5qkytex4qxsijdr5ydud2n3anvf@yakjfjg5ng4u/
drivers/dma/dmaengine.c | 13 ++++++++-----
drivers/dma/dw-edma/dw-edma-core.c | 1 +
include/linux/dmaengine.h | 20 ++++++++++++++++++++
3 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 6ffd8bd82154..cc64a4679e6f 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1078,6 +1078,7 @@ static int __dma_async_device_channel_register(struct dma_device *device,
struct dma_chan *chan,
const char *name)
{
+ unsigned int id;
int rc;
chan->local = alloc_percpu(typeof(*chan->local));
@@ -1089,11 +1090,13 @@ static int __dma_async_device_channel_register(struct dma_device *device,
goto err_free_local;
}
- /*
- * When the chan_id is a negative value, we are dynamically adding
- * the channel. Otherwise we are static enumerating.
- */
- chan->chan_id = ida_alloc(&device->chan_ida, GFP_KERNEL);
+ if (chan->chan_id & DMA_CHAN_ID_STATIC) {
+ id = chan->chan_id & ~DMA_CHAN_ID_STATIC;
+ chan->chan_id = ida_alloc_range(&device->chan_ida, id, id,
+ GFP_KERNEL);
+ } else {
+ chan->chan_id = ida_alloc(&device->chan_ida, GFP_KERNEL);
+ }
if (chan->chan_id < 0) {
pr_err("%s: unable to alloc ida for chan: %d\n",
__func__, chan->chan_id);
diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
index 1f893dc54c79..d214df55da3c 100644
--- a/drivers/dma/dw-edma/dw-edma-core.c
+++ b/drivers/dma/dw-edma/dw-edma-core.c
@@ -987,6 +987,7 @@ static int dw_edma_channel_setup(struct dw_edma *dw, u32 wr_alloc, u32 rd_alloc)
&dw->chip->dt_region_rd[chan->id];
vchan_init(&chan->vc, dma);
+ dmaengine_set_static_chan_id(&chan->vc.chan, i);
dw_edma_core_ch_config(chan);
}
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index fe33a20abc61..f669b79d7731 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -369,6 +369,26 @@ struct dma_chan {
void *private;
};
+#define DMA_CHAN_ID_STATIC BIT(30)
+
+/**
+ * dmaengine_set_static_chan_id - request an exact DMA engine channel ID
+ * @chan: DMA channel
+ * @id: channel ID, unique within the DMA device
+ *
+ * Drivers may call this after initializing @chan and before registering its
+ * DMA device. The dmaengine core reserves @id from the device IDA instead of
+ * assigning the next available ID.
+ */
+static inline void dmaengine_set_static_chan_id(struct dma_chan *chan,
+ unsigned int id)
+{
+ if (WARN_ON_ONCE(id >= DMA_CHAN_ID_STATIC))
+ return;
+
+ chan->chan_id = DMA_CHAN_ID_STATIC | id;
+}
+
/**
* struct dma_chan_dev - relate sysfs device node to backing channel device
* @chan: driver channel device
--
2.51.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v7 01/10] dmaengine: Allow drivers to assign static channel IDs
2026-08-13 6:37 ` [PATCH v7 01/10] dmaengine: Allow drivers to assign static channel IDs Koichiro Den
@ 2026-08-13 6:51 ` sashiko-bot
0 siblings, 0 replies; 25+ messages in thread
From: sashiko-bot @ 2026-08-13 6:51 UTC (permalink / raw)
To: Koichiro Den; +Cc: dmaengine, linux-pci, Frank.Li, vkoul
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
Pre-existing issues:
- [High] Memory and ID leak in the error rollback path of dma_async_device_register() when a subset of channels fail to register.
- [High] Directly calling kfree() on a device struct after device_register() fails, leading to kobject resource leaks and potential use-after-free.
- [High] dma_channel_rebalance() is called without holding dma_list_mutex when dynamically registering or unregistering channels.
- [Medium] device->chancnt is incremented without synchronization, leading to data races during dynamic channel registration.
--
--- Patch [1]: [PATCH v7 01/10] dmaengine: Allow drivers to assign static channel IDs ---
commit d88a921ed93cbdf57ab5a802c1f278694ad4200a
Author: Koichiro Den <den@valinux.co.jp>
dmaengine: Allow drivers to assign static channel IDs
The dmaengine core assigns channel IDs in registration order. If a driver skips
a hardware channel, chan_id can differ from the hardware numbering and a client
cannot reliably correlate a requested channel with hardware resources. Let a
driver request an exact channel ID before device registration.
Link: https://lore.kernel.org/r/lm7tadnxsyrypu4mypptlkx5qkytex4qxsijdr5ydud2n3anvf@yakjfjg5ng4u/
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 6ffd8bd82154a..cc64a4679e6fa 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -1078,6 +1078,7 @@ static int __dma_async_device_channel_register(struct dma_device *device,
> struct dma_chan *chan,
> const char *name)
> {
> + unsigned int id;
> int rc;
>
> chan->local = alloc_percpu(typeof(*chan->local));
[ ... ]
> - /*
> - * When the chan_id is a negative value, we are dynamically adding
> - * the channel. Otherwise we are static enumerating.
> - */
> - chan->chan_id = ida_alloc(&device->chan_ida, GFP_KERNEL);
> + if (chan->chan_id & DMA_CHAN_ID_STATIC) {
> + id = chan->chan_id & ~DMA_CHAN_ID_STATIC;
> + chan->chan_id = ida_alloc_range(&device->chan_ida, id, id,
> + GFP_KERNEL);
> + } else {
> + chan->chan_id = ida_alloc(&device->chan_ida, GFP_KERNEL);
> + }
> if (chan->chan_id < 0) {
> pr_err("%s: unable to alloc ida for chan: %d\n",
> __func__, chan->chan_id);
[Severity: High]
This is a pre-existing issue, but does the error rollback path in
dma_async_device_register() leak IDs?
drivers/dma/dmaengine.c:dma_async_device_register() {
...
err_out:
/* if we never registered a channel just release the idr */
if (!device->chancnt) {
ida_free(&dma_ida, device->dev_id);
return rc;
}
list_for_each_entry(chan, &device->channels, device_node) {
if (chan->local == NULL)
continue;
mutex_lock(&dma_list_mutex);
chan->dev->chan = NULL;
mutex_unlock(&dma_list_mutex);
device_unregister(&chan->dev->device);
free_percpu(chan->local);
}
return rc;
}
If channel registration fails and one or more channels were already successfully
registered (device->chancnt > 0), it skips ida_free(&dma_ida, device->dev_id).
Additionally, the rollback loop unregisters the previously successful channels
but appears to miss calling ida_free(&device->chan_ida, chan->chan_id), which
could permanently leak the channel IDs and their associated memory.
[Severity: High]
This is a pre-existing issue, but is it safe to use kfree() after
device_register() fails?
drivers/dma/dmaengine.c:__dma_async_device_channel_register() {
...
rc = device_register(&chan->dev->device);
if (rc)
goto err_out_ida;
...
err_out_ida:
ida_free(&device->chan_ida, chan->chan_id);
err_free_dev:
kfree(chan->dev);
err_free_local:
free_percpu(chan->local);
...
}
If device_register(&chan->dev->device) fails, the error handler directly calls
kfree(chan->dev).
Once device_initialize() has been called (internally by device_register()),
shouldn't put_device() be used to clean up the kobject state and avoid leaking
the device name string?
[Severity: High]
This is a pre-existing issue, but are these list operations safe from data
races?
drivers/dma/dmaengine.c:dma_async_device_channel_register() {
...
dma_channel_rebalance();
...
}
drivers/dma/dmaengine.c:dma_async_device_channel_unregister() {
...
dma_channel_rebalance();
...
}
When dynamically registering or unregistering channels, dma_channel_rebalance()
is called without acquiring dma_list_mutex.
Since dma_channel_rebalance() locklessly iterates over the global
dma_device_list, could this cause list corruption if another device is
concurrently registered or unregistered?
[Severity: Medium]
This is a pre-existing issue, but does device->chancnt need synchronization
here?
drivers/dma/dmaengine.c:__dma_async_device_channel_register() {
...
chan->client_count = 0;
device->chancnt++;
...
}
The increment device->chancnt++ is performed without holding dma_list_mutex or
any other lock.
If multiple channels are dynamically registered concurrently on the same device,
could updates to this counter be lost?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813063757.3131865-1-den@valinux.co.jp?part=1
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v7 02/10] PCI: endpoint: Define endpoint DMA BAR metadata format
2026-08-13 6:37 [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Koichiro Den
2026-08-13 6:37 ` [PATCH v7 01/10] dmaengine: Allow drivers to assign static channel IDs Koichiro Den
@ 2026-08-13 6:37 ` Koichiro Den
2026-08-13 6:40 ` sashiko-bot
2026-08-13 6:37 ` [PATCH v7 03/10] PCI: endpoint: Add DMA auxiliary resource metadata Koichiro Den
` (8 subsequent siblings)
10 siblings, 1 reply; 25+ messages in thread
From: Koichiro Den @ 2026-08-13 6:37 UTC (permalink / raw)
To: Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Frank Li, Bjorn Helgaas, Jonathan Corbet,
Shuah Khan, Randy Dunlap, Vinod Koul, Jingoo Han,
Lorenzo Pieralisi, Rob Herring, Niklas Cassel, Damien Le Moal,
Arnd Bergmann
Cc: Marek Vasut, Yoshihiro Shimoda, linux-pci, linux-doc,
linux-kernel, dmaengine
Define the BAR-resident metadata format used by endpoint functions that
expose an endpoint-integrated DMA controller to the host.
A VSEC-based discovery scheme would be a natural fit, and existing
dw-edma-pcie providers such as Synopsys EDDA and AMD (Xilinx) MDB/CPM6
already use VSECs for DMA discovery. However, some endpoint controllers
cannot provide enough writable configuration-space storage for a
complete, controller-defined payload. Keep the extensible metadata in a
BAR instead, where the endpoint function controls the layout and size.
The format describes the DMA register window, exported channel counts,
descriptor windows, optional auxiliary windows, endpoint-local descriptor
and auxiliary DMA addresses, and a ready bit that tells the host when the
described BAR windows are usable. Channel entries keep the auxiliary
window optional so layouts that need a separate data or auxiliary aperture
can describe it without a format bump.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
Changes in v7:
- Move HOST_REQ to a separate 32-bit word. (Frank)
- Increase the metadata header length to 0x20 accordingly.
MAINTAINERS | 1 +
include/linux/pci-ep-dma.h | 175 +++++++++++++++++++++++++++++++++++++
2 files changed, 176 insertions(+)
create mode 100644 include/linux/pci-ep-dma.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 15c7dc516f7c..d330178ac1f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20990,6 +20990,7 @@ F: Documentation/PCI/endpoint/*
F: Documentation/misc-devices/pci-endpoint-test.rst
F: drivers/misc/pci_endpoint_test.c
F: drivers/pci/endpoint/
+F: include/linux/pci-ep-dma.h
F: tools/testing/selftests/pci_endpoint/
PCI ENHANCED ERROR HANDLING (EEH) FOR POWERPC
diff --git a/include/linux/pci-ep-dma.h b/include/linux/pci-ep-dma.h
new file mode 100644
index 000000000000..03b48ee7669e
--- /dev/null
+++ b/include/linux/pci-ep-dma.h
@@ -0,0 +1,175 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __LINUX_PCI_EP_DMA_H
+#define __LINUX_PCI_EP_DMA_H
+
+#include <linux/bits.h>
+
+/*
+ * BAR metadata format used by PCI endpoint functions that expose an
+ * endpoint-integrated DMA controller to a PCI host.
+ *
+ * Offsets are relative to the beginning of the metadata blob. Multi-byte
+ * fields are little-endian. The blob is normally placed at offset 0 of a
+ * function BAR selected by the endpoint function and discovered by the host
+ * driver using device-specific policy. Other data in the same BAR, such as a
+ * standard MSI-X table or PBA, is outside this metadata format.
+ *
+ * 31 0
+ * +---------------------------------------------------------------+
+ * +0x000 | metadata magic |
+ * +---------------------------------------------------------------+
+ * 31 16 15 8 7 0
+ * +-------------------------------+---------------+---------------+
+ * +0x004 | metadata length | reserved | revision |
+ * +-------------------------------+---------------+---------------+
+ * 31 30 27 26 19 18 11 10 3 2 0
+ * +--+------------+--------------+--------------+-------------+---+
+ * +0x008 |R | reserved | ch entry size| RD count | WR count |BAR|
+ * +--+------------+--------------+--------------+-------------+---+
+ * +0x00c | register window offset[31:0] |
+ * +---------------------------------------------------------------+
+ * +0x010 | register window offset[63:32] |
+ * +---------------------------------------------------------------+
+ * 31 16 15 8 7 0
+ * +-------------------------------+---------------+---------------+
+ * +0x014 | reserved | layout data | layout |
+ * +-------------------------------+---------------+---------------+
+ * +0x018 | register window size |
+ * +---------------------------------------------------------------+
+ * 31 1 0
+ * +-------------------------------------------------------------+-+
+ * +0x01c | reserved |H|
+ * +-------------------------------------------------------------+-+
+ * +0x020 | write table |
+ * | ( channel table entries #0 ~ #N ) |
+ * +---------------------------------------------------------------+
+ * | read table |
+ * | ( channel table entries #0 ~ #N ) |
+ * +---------------------------------------------------------------+
+ *
+ * metadata magic: PCI_EP_DMA_METADATA_MAGIC.
+ * metadata length: byte size of the whole metadata blob. The value
+ * must fit in PCI_EP_DMA_METADATA_HDR_LEN_FIELD and
+ * in the BAR allocation that contains the metadata.
+ * revision: metadata format revision.
+ * R: ready bit. Set only by the endpoint after all fields and BAR
+ * windows described by this metadata have been programmed and can
+ * be used by the host. The host must not consume the windows
+ * before observing this bit.
+ * H: host-request bit. Set only by the host driver after it has found
+ * this metadata. The endpoint may use this as the trigger to
+ * program DMA window BAR subrange mappings, and may clear it while
+ * revoking R during teardown or reinitialization.
+ * ch entry size: byte stride between consecutive channel table
+ * entries. Revision 1 requires at least
+ * PCI_EP_DMA_METADATA_CH_ENTRY_SIZE bytes.
+ * RD count: number of exposed RC-to-endpoint DMA read channels and
+ * read channel-table entries.
+ * WR count: number of exposed endpoint-to-RC DMA write channels and
+ * write channel-table entries.
+ * BAR: BAR that contains the DMA controller register window.
+ * register window offset: BAR-local byte offset of the DMA controller
+ * register window in BAR.
+ * register window size: DMA controller register window size in bytes.
+ * layout: DMA controller register layout identifier.
+ * layout data: layout-specific data. For
+ * PCI_EP_DMA_METADATA_REG_LAYOUT_DW_EDMA this is the
+ * DesignWare eDMA/HDMA map format.
+ * write table: starts at PCI_EP_DMA_METADATA_HDR_LEN if write channel
+ * count is non-zero.
+ * read table: starts at PCI_EP_DMA_METADATA_HDR_LEN plus the write
+ * table size if read channel count is non-zero.
+ * reserved fields and bits: write zero and ignore on read.
+ *
+ *
+ * Channel table entry:
+ *
+ * 31 17 16 15 14 12 11 10 8 7 0
+ * +--------------------+--+--+-------+--+--------+----------------+
+ * +0x000 | reserved |A |rs|aux BAR|rs|desc BAR|hardware channel|
+ * +--------------------+--+--+-------+--+--------+----------------+
+ * +0x004 | descriptor window BAR offset[31:0] |
+ * +---------------------------------------------------------------+
+ * +0x008 | descriptor window BAR offset[63:32] |
+ * +---------------------------------------------------------------+
+ * +0x00c | descriptor window size |
+ * +---------------------------------------------------------------+
+ * +0x010 | descriptor DMA address[31:0] |
+ * +---------------------------------------------------------------+
+ * +0x014 | descriptor DMA address[63:32] |
+ * +---------------------------------------------------------------+
+ * +0x018 | auxiliary window BAR offset[31:0] |
+ * +---------------------------------------------------------------+
+ * +0x01c | auxiliary window BAR offset[63:32] |
+ * +---------------------------------------------------------------+
+ * +0x020 | auxiliary window size |
+ * +---------------------------------------------------------------+
+ * +0x024 | auxiliary DMA address[31:0] |
+ * +---------------------------------------------------------------+
+ * +0x028 | auxiliary DMA address[63:32] |
+ * +---------------------------------------------------------------+
+ *
+ * A: auxiliary-window-valid bit. If clear, aux BAR and auxiliary
+ * window fields are ignored.
+ * aux BAR: BAR that contains the optional auxiliary window.
+ * desc BAR: BAR that contains the descriptor window.
+ * hardware channel: DMA controller's hardware channel number.
+ * Revision 1 entries are currently consumed in dense
+ * 0-based order.
+ * descriptor window BAR offset: BAR-local byte offset of the
+ * descriptor window in desc BAR.
+ * descriptor window size: descriptor window size in bytes.
+ * descriptor DMA address: endpoint-local address used by the DMA
+ * controller to fetch descriptors.
+ * auxiliary window BAR offset: BAR-local byte offset of the auxiliary
+ * window in aux BAR.
+ * auxiliary window size: auxiliary window size in bytes.
+ * auxiliary DMA address: endpoint-local address corresponding to the
+ * auxiliary window.
+ * reserved fields and bits: write zero and ignore on read.
+ */
+#define PCI_EP_DMA_METADATA_MAGIC 0x4d444550 /* "PEDM" */
+#define PCI_EP_DMA_METADATA_REV 0x1
+
+#define PCI_EP_DMA_METADATA_HDR_LEN 0x20
+
+#define PCI_EP_DMA_METADATA_HDR 0x04
+#define PCI_EP_DMA_METADATA_HDR_REV GENMASK(7, 0)
+#define PCI_EP_DMA_METADATA_HDR_LEN_FIELD GENMASK(31, 16)
+
+#define PCI_EP_DMA_METADATA_CTRL 0x08
+#define PCI_EP_DMA_METADATA_CTRL_REG_BAR GENMASK(2, 0)
+#define PCI_EP_DMA_METADATA_CTRL_WR_CH_COUNT GENMASK(10, 3)
+#define PCI_EP_DMA_METADATA_CTRL_RD_CH_COUNT GENMASK(18, 11)
+#define PCI_EP_DMA_METADATA_CTRL_CH_ENTRY_SIZE GENMASK(26, 19)
+#define PCI_EP_DMA_METADATA_CTRL_READY BIT(31)
+
+#define PCI_EP_DMA_METADATA_REG_OFF_LO 0x0c
+#define PCI_EP_DMA_METADATA_REG_OFF_HI 0x10
+#define PCI_EP_DMA_METADATA_REG_LAYOUT 0x14
+#define PCI_EP_DMA_METADATA_REG_LAYOUT_ID GENMASK(7, 0)
+#define PCI_EP_DMA_METADATA_REG_LAYOUT_DATA GENMASK(15, 8)
+#define PCI_EP_DMA_METADATA_REG_SIZE 0x18
+#define PCI_EP_DMA_METADATA_HOST_CTRL 0x1c
+#define PCI_EP_DMA_METADATA_HOST_CTRL_REQ BIT(0)
+
+#define PCI_EP_DMA_METADATA_REG_LAYOUT_DW_EDMA 0x1
+
+#define PCI_EP_DMA_METADATA_CH_ENTRY_SIZE 0x2c
+#define PCI_EP_DMA_METADATA_CH_CTRL 0x00
+#define PCI_EP_DMA_METADATA_CH_CTRL_HW_CH GENMASK(7, 0)
+#define PCI_EP_DMA_METADATA_CH_CTRL_DESC_BAR GENMASK(10, 8)
+#define PCI_EP_DMA_METADATA_CH_CTRL_AUX_BAR GENMASK(14, 12)
+#define PCI_EP_DMA_METADATA_CH_CTRL_AUX_VALID BIT(16)
+#define PCI_EP_DMA_METADATA_CH_DESC_OFF_LO 0x04
+#define PCI_EP_DMA_METADATA_CH_DESC_OFF_HI 0x08
+#define PCI_EP_DMA_METADATA_CH_DESC_SIZE 0x0c
+#define PCI_EP_DMA_METADATA_CH_DESC_ADDR_LO 0x10
+#define PCI_EP_DMA_METADATA_CH_DESC_ADDR_HI 0x14
+#define PCI_EP_DMA_METADATA_CH_AUX_OFF_LO 0x18
+#define PCI_EP_DMA_METADATA_CH_AUX_OFF_HI 0x1c
+#define PCI_EP_DMA_METADATA_CH_AUX_SIZE 0x20
+#define PCI_EP_DMA_METADATA_CH_AUX_ADDR_LO 0x24
+#define PCI_EP_DMA_METADATA_CH_AUX_ADDR_HI 0x28
+
+#endif /* __LINUX_PCI_EP_DMA_H */
--
2.51.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v7 02/10] PCI: endpoint: Define endpoint DMA BAR metadata format
2026-08-13 6:37 ` [PATCH v7 02/10] PCI: endpoint: Define endpoint DMA BAR metadata format Koichiro Den
@ 2026-08-13 6:40 ` sashiko-bot
0 siblings, 0 replies; 25+ messages in thread
From: sashiko-bot @ 2026-08-13 6:40 UTC (permalink / raw)
To: Koichiro Den; +Cc: vkoul, linux-pci, Frank.Li, dmaengine
> Define the BAR-resident metadata format used by endpoint functions that
> expose an endpoint-integrated DMA controller to the host.
>
> A VSEC-based discovery scheme would be a natural fit, and existing
> dw-edma-pcie providers such as Synopsys EDDA and AMD (Xilinx) MDB/CPM6
> already use VSECs for DMA discovery. However, some endpoint controllers
> cannot provide enough writable configuration-space storage for a
> complete, controller-defined payload. Keep the extensible metadata in a
> BAR instead, where the endpoint function controls the layout and size.
>
> The format describes the DMA register window, exported channel counts,
> descriptor windows, optional auxiliary windows, endpoint-local descriptor
> and auxiliary DMA addresses, and a ready bit that tells the host when the
> described BAR windows are usable. Channel entries keep the auxiliary
> window optional so layouts that need a separate data or auxiliary aperture
> can describe it without a format bump.
>
> Signed-off-by: Koichiro Den <den@valinux.co.jp>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813063757.3131865-1-den@valinux.co.jp?part=2
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v7 03/10] PCI: endpoint: Add DMA auxiliary resource metadata
2026-08-13 6:37 [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Koichiro Den
2026-08-13 6:37 ` [PATCH v7 01/10] dmaengine: Allow drivers to assign static channel IDs Koichiro Den
2026-08-13 6:37 ` [PATCH v7 02/10] PCI: endpoint: Define endpoint DMA BAR metadata format Koichiro Den
@ 2026-08-13 6:37 ` Koichiro Den
2026-08-13 6:41 ` sashiko-bot
2026-08-13 6:37 ` [PATCH v7 04/10] PCI: endpoint: Add API to delegate EPC DMA channels to the host Koichiro Den
` (7 subsequent siblings)
10 siblings, 1 reply; 25+ messages in thread
From: Koichiro Den @ 2026-08-13 6:37 UTC (permalink / raw)
To: Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Frank Li, Bjorn Helgaas, Jonathan Corbet,
Shuah Khan, Randy Dunlap, Vinod Koul, Jingoo Han,
Lorenzo Pieralisi, Rob Herring, Niklas Cassel, Damien Le Moal,
Arnd Bergmann
Cc: Marek Vasut, Yoshihiro Shimoda, linux-pci, linux-doc,
linux-kernel, dmaengine
Extend EPC auxiliary resource metadata so endpoint functions can
discover controller-owned DMA registers, logical DMA channels, and
descriptor memory.
The DMA metadata is intentionally generic at the EPC layer. A backend
reports the register layout, channel counts, logical channel resources,
and descriptor memory resources. Logical channels carry hardware channel
numbers, identify their corresponding local DMA engine device and static
channel ID, and refer to descriptor memory by ID. Descriptor memory is
identified separately so one memory resource can be shared by multiple
channels.
For DesignWare controllers, reg_layout_data carries the eDMA/HDMA map
format so a consumer can distinguish legacy, unroll, HDMA compatible,
and HDMA native register layouts without making the EPC API itself
DesignWare-specific.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
Changes in v7:
- Identify each local DMA engine channel by device and static channel ID,
per discussion with Frank on v6 patch 4.
@Frank, I haven't picked up your R-b tag because this patch has changed.
Please take another look, thanks.
include/linux/pci-epc.h | 48 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index f247cf9bcf1a..3b60cf6628e2 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -65,6 +65,9 @@ struct pci_epc_map {
* enum pci_epc_aux_resource_type - auxiliary resource type identifiers
* @PCI_EPC_AUX_DOORBELL_MMIO: Doorbell MMIO, that might be outside the DMA
* controller register window
+ * @PCI_EPC_AUX_DMA_CTRL_MMIO: DMA controller MMIO register window
+ * @PCI_EPC_AUX_DMA_CHAN: Logical DMA channel
+ * @PCI_EPC_AUX_DMA_DESC_MEM: DMA descriptor memory
*
* EPC backends may expose auxiliary blocks (e.g. DMA engines) by mapping their
* register windows and descriptor memories into BAR space. This enum
@@ -72,6 +75,29 @@ struct pci_epc_map {
*/
enum pci_epc_aux_resource_type {
PCI_EPC_AUX_DOORBELL_MMIO,
+ PCI_EPC_AUX_DMA_CTRL_MMIO,
+ PCI_EPC_AUX_DMA_CHAN,
+ PCI_EPC_AUX_DMA_DESC_MEM,
+};
+
+/**
+ * enum pci_epc_aux_dma_reg_layout - DMA controller register layout
+ * @PCI_EPC_AUX_DMA_REG_LAYOUT_UNKNOWN: unknown or uninitialized layout
+ * @PCI_EPC_AUX_DMA_REG_LAYOUT_DW_EDMA: Synopsys DesignWare eDMA/HDMA layout
+ */
+enum pci_epc_aux_dma_reg_layout {
+ PCI_EPC_AUX_DMA_REG_LAYOUT_UNKNOWN = 0,
+ PCI_EPC_AUX_DMA_REG_LAYOUT_DW_EDMA,
+};
+
+/**
+ * enum pci_epc_aux_dma_dir - DMA channel direction relative to the endpoint
+ * @PCI_EPC_AUX_DMA_EP_TO_RC: channel moves data from endpoint to root complex
+ * @PCI_EPC_AUX_DMA_RC_TO_EP: channel moves data from root complex to endpoint
+ */
+enum pci_epc_aux_dma_dir {
+ PCI_EPC_AUX_DMA_EP_TO_RC,
+ PCI_EPC_AUX_DMA_RC_TO_EP,
};
/**
@@ -99,6 +125,28 @@ struct pci_epc_aux_resource {
int irq; /* IRQ number for the doorbell handler */
u32 data; /* write value to ring the doorbell */
} db_mmio;
+
+ /* PCI_EPC_AUX_DMA_CTRL_MMIO */
+ struct {
+ enum pci_epc_aux_dma_reg_layout reg_layout;
+ u32 reg_layout_data;
+ u16 ep_to_rc_ch_cnt;
+ u16 rc_to_ep_ch_cnt;
+ } dma_ctrl;
+
+ /* PCI_EPC_AUX_DMA_CHAN */
+ struct {
+ struct device *dma_dev;
+ int chan_id; /* Local dmaengine ID, unique within dma_dev */
+ enum pci_epc_aux_dma_dir dir;
+ u16 hw_ch; /* Direction-local hardware channel exposed to the host */
+ u16 desc_mem_id;
+ } dma_chan;
+
+ /* PCI_EPC_AUX_DMA_DESC_MEM */
+ struct {
+ u16 id;
+ } dma_desc;
} u;
};
--
2.51.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v7 03/10] PCI: endpoint: Add DMA auxiliary resource metadata
2026-08-13 6:37 ` [PATCH v7 03/10] PCI: endpoint: Add DMA auxiliary resource metadata Koichiro Den
@ 2026-08-13 6:41 ` sashiko-bot
0 siblings, 0 replies; 25+ messages in thread
From: sashiko-bot @ 2026-08-13 6:41 UTC (permalink / raw)
To: Koichiro Den; +Cc: linux-pci, dmaengine, vkoul, Frank.Li
> Extend EPC auxiliary resource metadata so endpoint functions can
> discover controller-owned DMA registers, logical DMA channels, and
> descriptor memory.
>
> The DMA metadata is intentionally generic at the EPC layer. A backend
> reports the register layout, channel counts, logical channel resources,
> and descriptor memory resources. Logical channels carry hardware channel
> numbers, identify their corresponding local DMA engine device and static
> channel ID, and refer to descriptor memory by ID. Descriptor memory is
> identified separately so one memory resource can be shared by multiple
> channels.
>
> For DesignWare controllers, reg_layout_data carries the eDMA/HDMA map
> format so a consumer can distinguish legacy, unroll, HDMA compatible,
> and HDMA native register layouts without making the EPC API itself
> DesignWare-specific.
>
> Signed-off-by: Koichiro Den <den@valinux.co.jp>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813063757.3131865-1-den@valinux.co.jp?part=3
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v7 04/10] PCI: endpoint: Add API to delegate EPC DMA channels to the host
2026-08-13 6:37 [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Koichiro Den
` (2 preceding siblings ...)
2026-08-13 6:37 ` [PATCH v7 03/10] PCI: endpoint: Add DMA auxiliary resource metadata Koichiro Den
@ 2026-08-13 6:37 ` Koichiro Den
2026-08-13 6:46 ` sashiko-bot
2026-08-13 6:37 ` [PATCH v7 05/10] dmaengine: dw-edma: Add channel delegation helpers Koichiro Den
` (6 subsequent siblings)
10 siblings, 1 reply; 25+ messages in thread
From: Koichiro Den @ 2026-08-13 6:37 UTC (permalink / raw)
To: Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Frank Li, Bjorn Helgaas, Jonathan Corbet,
Shuah Khan, Randy Dunlap, Vinod Koul, Jingoo Han,
Lorenzo Pieralisi, Rob Herring, Niklas Cassel, Damien Le Moal,
Arnd Bergmann
Cc: Marek Vasut, Yoshihiro Shimoda, linux-pci, linux-doc,
linux-kernel, dmaengine
Some endpoint functions expose an EPC-integrated DMA controller to the
host. The endpoint function reserves the local DMA engine channel, but
should not need to know the backend-specific mechanism used to hand its
programming interface to the host.
Add pci_epc_delegate_dma_chan() and pci_epc_reclaim_dma_chan().
Add matching EPC operations. They pass an already reserved dma_chan to
the backend. This lets generic endpoint functions delegate channels
without depending on a specific DMA engine driver. The caller retains
the dmaengine reservation until reclaim completes.
Let reclaim callers tell the backend whether hardware exposed to host
programming needs to be quiesced before local ownership is restored.
The quiesce may cover a provider-defined sharing group, so callers must
hold every delegated member and stop peer programming before reclaim.
Bind failure paths that only unwind local reservations can skip quiesce.
Reclaim is best-effort because it runs from teardown paths that cannot be
aborted. The backend always consumes the delegation and reports any
quiesce failure itself.
Suggested-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
Changes in v7:
- Take an already reserved DMA engine channel and leave its lifetime to
the endpoint function, per discussion with Frank on v6 patch 4.
- Remove the opaque pci_epc_dma_chan handle and pass the EPC and function
identity explicitly on reclaim.
@Frank, I haven't picked up your R-b tag because the API has changed.
Please take another look, thanks.
drivers/pci/endpoint/pci-epc-core.c | 70 +++++++++++++++++++++++++++++
include/linux/pci-epc.h | 15 +++++++
2 files changed, 85 insertions(+)
diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
index 831b40458dcd..d0bcf3dc7039 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -236,6 +236,76 @@ int pci_epc_get_aux_resources(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
}
EXPORT_SYMBOL_GPL(pci_epc_get_aux_resources);
+/**
+ * pci_epc_delegate_dma_chan() - delegate an EPC-owned DMA channel to the host
+ * @epc: EPC device
+ * @func_no: function number
+ * @vfunc_no: virtual function number
+ * @chan: DMA engine channel reserved by the endpoint function
+ *
+ * Some EPC backends integrate DMA channels that can be exposed to the host.
+ * This helper asks the backend to hand a channel already reserved through
+ * dmaengine to the host and place it in a state where the host driver may
+ * program it through the exposed register window.
+ *
+ * Return: 0 on success, -EOPNOTSUPP if the backend does not support DMA channel
+ * delegation, or another -errno on failure.
+ */
+int pci_epc_delegate_dma_chan(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+ struct dma_chan *chan)
+{
+ int ret;
+
+ if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
+ return -EINVAL;
+
+ if (!chan)
+ return -EINVAL;
+
+ if (!epc->ops->delegate_dma_chan || !epc->ops->reclaim_dma_chan)
+ return -EOPNOTSUPP;
+
+ mutex_lock(&epc->lock);
+ ret = epc->ops->delegate_dma_chan(epc, func_no, vfunc_no, chan);
+ mutex_unlock(&epc->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pci_epc_delegate_dma_chan);
+
+/**
+ * pci_epc_reclaim_dma_chan() - reclaim a delegated EPC-owned DMA channel
+ * @epc: EPC device
+ * @func_no: function number used when delegating @chan
+ * @vfunc_no: virtual function number used when delegating @chan
+ * @chan: delegated DMA engine channel
+ * @quiesce: quiesce affected hardware before reclaiming the channel
+ *
+ * Reclaim a channel previously delegated to the host. Set @quiesce for channels
+ * that may have been exposed to host programming. Bind failure paths that are
+ * unwinding local reservations before exposure may leave it clear.
+ *
+ * Some providers share enable and interrupt controls among channels. The
+ * caller must retain every delegated member of that sharing group and prevent
+ * further peer programming before requesting reclaim.
+ *
+ * Reclaim is best-effort because it runs from teardown paths that cannot be
+ * aborted. The backend always consumes the delegation and reports any quiesce
+ * failure itself. The caller retains the DMA engine channel reservation and
+ * releases it after this function returns.
+ */
+void pci_epc_reclaim_dma_chan(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+ struct dma_chan *chan, bool quiesce)
+{
+ if (!epc || !chan || !epc->ops->reclaim_dma_chan)
+ return;
+
+ mutex_lock(&epc->lock);
+ epc->ops->reclaim_dma_chan(epc, func_no, vfunc_no, chan, quiesce);
+ mutex_unlock(&epc->lock);
+}
+EXPORT_SYMBOL_GPL(pci_epc_reclaim_dma_chan);
+
/**
* 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 3b60cf6628e2..3b0aaaa9a259 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -11,6 +11,8 @@
#include <linux/pci-epf.h>
+struct device;
+struct dma_chan;
struct pci_epc;
enum pci_epc_interface_type {
@@ -176,6 +178,11 @@ struct pci_epc_aux_resource {
* @get_aux_resources_count: ops to get the number of controller-owned
* auxiliary resources
* @get_aux_resources: ops to retrieve controller-owned auxiliary resources
+ * @delegate_dma_chan: ops to delegate a controller-owned DMA channel to the
+ * host
+ * @reclaim_dma_chan: ops to reclaim a previously delegated DMA channel.
+ * The callback quiesces the channel or its provider-defined
+ * sharing group when requested.
* @owner: the module owner containing the ops
*/
struct pci_epc_ops {
@@ -212,6 +219,10 @@ struct pci_epc_ops {
int (*get_aux_resources)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
struct pci_epc_aux_resource *resources,
int num_resources);
+ int (*delegate_dma_chan)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+ struct dma_chan *chan);
+ void (*reclaim_dma_chan)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+ struct dma_chan *chan, bool quiesce);
struct module *owner;
};
@@ -445,6 +456,10 @@ int pci_epc_get_aux_resources_count(struct pci_epc *epc, u8 func_no,
int pci_epc_get_aux_resources(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
struct pci_epc_aux_resource *resources,
int num_resources);
+int pci_epc_delegate_dma_chan(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+ struct dma_chan *chan);
+void pci_epc_reclaim_dma_chan(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+ struct dma_chan *chan, bool quiesce);
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
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v7 04/10] PCI: endpoint: Add API to delegate EPC DMA channels to the host
2026-08-13 6:37 ` [PATCH v7 04/10] PCI: endpoint: Add API to delegate EPC DMA channels to the host Koichiro Den
@ 2026-08-13 6:46 ` sashiko-bot
0 siblings, 0 replies; 25+ messages in thread
From: sashiko-bot @ 2026-08-13 6:46 UTC (permalink / raw)
To: Koichiro Den; +Cc: vkoul, linux-pci, Frank.Li, dmaengine
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] `pci_epc_reclaim_dma_chan()` fails to validate the `epc` pointer for `ERR_PTR` values and omits function number bounds checks.
--
--- Patch [4]: [PATCH v7 04/10] PCI: endpoint: Add API to delegate EPC DMA channels to the host ---
commit de98f70ea5d6f77029b0c89f0e6b02055a9ff0a1
Author: Koichiro Den <den@valinux.co.jp>
PCI: endpoint: Add API to delegate EPC DMA channels to the host
This commit introduces pci_epc_delegate_dma_chan() and
pci_epc_reclaim_dma_chan() to allow endpoint functions to expose an
integrated DMA controller to the host. The endpoint reserves the local DMA
engine channel and passes it to the backend. Reclaiming allows the caller
to specify whether the hardware needs to be quiesced before local ownership
is restored.
> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index 831b40458dcd8..d0bcf3dc7039b 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c
[ ... ]
> +void pci_epc_reclaim_dma_chan(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> + struct dma_chan *chan, bool quiesce)
> +{
> + if (!epc || !chan || !epc->ops->reclaim_dma_chan)
> + return;
[Severity: Medium]
Should this use pci_epc_function_is_valid(epc, func_no, vfunc_no) here
instead of just checking !epc?
If an error pointer is passed during a teardown path, the !epc check will
fail to catch it, leading to a potential crash when dereferencing epc->ops.
Additionally, missing pci_epc_function_is_valid() means the func_no and
vfunc_no bounds are completely unvalidated before reaching the backend ops,
which could lead to out-of-bounds accesses in the backend drivers.
> +
> + mutex_lock(&epc->lock);
> + epc->ops->reclaim_dma_chan(epc, func_no, vfunc_no, chan, quiesce);
> + mutex_unlock(&epc->lock);
> +}
> +EXPORT_SYMBOL_GPL(pci_epc_reclaim_dma_chan);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813063757.3131865-1-den@valinux.co.jp?part=4
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v7 05/10] dmaengine: dw-edma: Add channel delegation helpers
2026-08-13 6:37 [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Koichiro Den
` (3 preceding siblings ...)
2026-08-13 6:37 ` [PATCH v7 04/10] PCI: endpoint: Add API to delegate EPC DMA channels to the host Koichiro Den
@ 2026-08-13 6:37 ` Koichiro Den
2026-08-13 6:50 ` sashiko-bot
2026-08-13 6:37 ` [PATCH v7 06/10] PCI: dwc: Implement endpoint DMA channel delegation Koichiro Den
` (5 subsequent siblings)
10 siblings, 1 reply; 25+ messages in thread
From: Koichiro Den @ 2026-08-13 6:37 UTC (permalink / raw)
To: Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Frank Li, Bjorn Helgaas, Jonathan Corbet,
Shuah Khan, Randy Dunlap, Vinod Koul, Jingoo Han,
Lorenzo Pieralisi, Rob Herring, Niklas Cassel, Damien Le Moal,
Arnd Bergmann
Cc: Marek Vasut, Yoshihiro Shimoda, linux-pci, linux-doc,
linux-kernel, dmaengine
Endpoint functions that expose endpoint-local DesignWare eDMA channels
to a remote host need to reserve exact hardware channels and hand
interrupt ownership to the remote side before publishing the channels.
Add DW eDMA-specific helpers that validate an idle, already reserved
channel and switch it to remote interrupt routing. The matching reclaim
helper can quiesce the channel while it is still remote-routed, then
restores the channel's default routing. The dmaengine channel reservation
remains with the caller.
Reclaim is best-effort because its callers cannot abort teardown. Report
a quiesce failure locally, but always restore the default routing.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
Changes in v7:
- Leave dmaengine channel selection and lifetime management to the
endpoint function, per discussion with Frank on v6 patch 4.
drivers/dma/dw-edma/dw-edma-core.c | 39 ++++++++++++++++++++++++++++++
include/linux/dma/edma.h | 11 +++++++++
2 files changed, 50 insertions(+)
diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
index d214df55da3c..1582ecfc2965 100644
--- a/drivers/dma/dw-edma/dw-edma-core.c
+++ b/drivers/dma/dw-edma/dw-edma-core.c
@@ -1303,6 +1303,45 @@ int dw_edma_remove(struct dw_edma_chip *chip)
}
EXPORT_SYMBOL_GPL(dw_edma_remove);
+int dw_edma_delegate_chan(struct dma_chan *dchan)
+{
+ struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
+ int ret = 0;
+
+ if (!(chan->dw->chip->flags & DW_EDMA_CHIP_LOCAL))
+ return -EINVAL;
+
+ guard(spinlock_irqsave)(&chan->vc.lock);
+
+ if (chan->configured || chan->status != EDMA_ST_IDLE ||
+ chan->request != EDMA_REQ_NONE)
+ ret = -EBUSY;
+ else
+ chan->irq_mode = DW_EDMA_CH_IRQ_REMOTE;
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(dw_edma_delegate_chan);
+
+void dw_edma_reclaim_chan(struct dma_chan *dchan, bool quiesce)
+{
+ struct dw_edma_chan *chan;
+
+ if (!dchan)
+ return;
+
+ chan = dchan2dw_edma_chan(dchan);
+ if (quiesce && dw_edma_core_ch_quiesce(chan))
+ dev_warn(chan->dw->chip->dev,
+ "failed to quiesce delegated %s channel %u\n",
+ chan->dir == EDMA_DIR_WRITE ? "write" : "read",
+ chan->id);
+
+ scoped_guard(spinlock_irqsave, &chan->vc.lock)
+ chan->irq_mode = dw_edma_get_default_irq_mode(chan);
+}
+EXPORT_SYMBOL_GPL(dw_edma_reclaim_chan);
+
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("Synopsys DesignWare eDMA controller core driver");
MODULE_AUTHOR("Gustavo Pimentel <gustavo.pimentel@synopsys.com>");
diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h
index 3c8e2ef9dee0..61ebb808981e 100644
--- a/include/linux/dma/edma.h
+++ b/include/linux/dma/edma.h
@@ -153,6 +153,8 @@ struct dw_edma_chip {
#if IS_REACHABLE(CONFIG_DW_EDMA)
int dw_edma_probe(struct dw_edma_chip *chip);
int dw_edma_remove(struct dw_edma_chip *chip);
+int dw_edma_delegate_chan(struct dma_chan *chan);
+void dw_edma_reclaim_chan(struct dma_chan *chan, bool quiesce);
#else
static inline int dw_edma_probe(struct dw_edma_chip *chip)
{
@@ -163,6 +165,15 @@ static inline int dw_edma_remove(struct dw_edma_chip *chip)
{
return 0;
}
+
+static inline int dw_edma_delegate_chan(struct dma_chan *chan)
+{
+ return -ENODEV;
+}
+
+static inline void dw_edma_reclaim_chan(struct dma_chan *chan, bool quiesce)
+{
+}
#endif /* CONFIG_DW_EDMA */
#endif /* _DW_EDMA_H */
--
2.51.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v7 05/10] dmaengine: dw-edma: Add channel delegation helpers
2026-08-13 6:37 ` [PATCH v7 05/10] dmaengine: dw-edma: Add channel delegation helpers Koichiro Den
@ 2026-08-13 6:50 ` sashiko-bot
0 siblings, 0 replies; 25+ messages in thread
From: sashiko-bot @ 2026-08-13 6:50 UTC (permalink / raw)
To: Koichiro Den; +Cc: dmaengine, Frank.Li, vkoul, linux-pci
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Data race on `chan->irq_mode` between channel delegation/reclaim and the hardirq handler.
--
--- Patch [5]: [PATCH v7 05/10] dmaengine: dw-edma: Add channel delegation helpers ---
commit ada234f341417a6397309d554f4e6b955a5ce106
Author: Koichiro Den <den@valinux.co.jp>
dmaengine: dw-edma: Add channel delegation helpers
This commit introduces helper functions to delegate endpoint-local
DesignWare eDMA channels to a remote host. It adds dw_edma_delegate_chan()
to switch an idle channel to remote interrupt routing, and
dw_edma_reclaim_chan() to restore the channel's default routing.
> diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
> index d214df55da3c3..1582ecfc2965f 100644
> --- a/drivers/dma/dw-edma/dw-edma-core.c
> +++ b/drivers/dma/dw-edma/dw-edma-core.c
[ ... ]
> @@ -1303,6 +1303,45 @@ int dw_edma_remove(struct dw_edma_chip *chip)
> }
> EXPORT_SYMBOL_GPL(dw_edma_remove);
>
> +int dw_edma_delegate_chan(struct dma_chan *dchan)
> +{
> + struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
> + int ret = 0;
> +
> + if (!(chan->dw->chip->flags & DW_EDMA_CHIP_LOCAL))
> + return -EINVAL;
> +
> + guard(spinlock_irqsave)(&chan->vc.lock);
> +
> + if (chan->configured || chan->status != EDMA_ST_IDLE ||
> + chan->request != EDMA_REQ_NONE)
> + ret = -EBUSY;
> + else
> + chan->irq_mode = DW_EDMA_CH_IRQ_REMOTE;
[Severity: Medium]
Does this introduce a data race on chan->irq_mode?
The irq_mode is updated here using a plain store while chan->vc.lock is held,
but it appears to be read locklessly during interrupt handling:
drivers/dma/dw-edma/dw-edma-core.h:dw_edma_core_ch_ignore_irq() {
return chan->irq_mode == DW_EDMA_CH_IRQ_REMOTE;
}
Could the compiler optimize or tear these plain accesses, potentially causing
the interrupt handler to incorrectly ignore or process a spurious interrupt,
or trigger KCSAN warnings? Would using WRITE_ONCE() and READ_ONCE() be
appropriate here?
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(dw_edma_delegate_chan);
> +
> +void dw_edma_reclaim_chan(struct dma_chan *dchan, bool quiesce)
> +{
> + struct dw_edma_chan *chan;
> +
> + if (!dchan)
> + return;
> +
> + chan = dchan2dw_edma_chan(dchan);
> + if (quiesce && dw_edma_core_ch_quiesce(chan))
> + dev_warn(chan->dw->chip->dev,
> + "failed to quiesce delegated %s channel %u\n",
> + chan->dir == EDMA_DIR_WRITE ? "write" : "read",
> + chan->id);
> +
> + scoped_guard(spinlock_irqsave, &chan->vc.lock)
> + chan->irq_mode = dw_edma_get_default_irq_mode(chan);
[Severity: Medium]
Similarly, does this plain store also race with the lockless read in
dw_edma_core_ch_ignore_irq()?
> +}
> +EXPORT_SYMBOL_GPL(dw_edma_reclaim_chan);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813063757.3131865-1-den@valinux.co.jp?part=5
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v7 06/10] PCI: dwc: Implement endpoint DMA channel delegation
2026-08-13 6:37 [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Koichiro Den
` (4 preceding siblings ...)
2026-08-13 6:37 ` [PATCH v7 05/10] dmaengine: dw-edma: Add channel delegation helpers Koichiro Den
@ 2026-08-13 6:37 ` Koichiro Den
2026-08-13 6:47 ` sashiko-bot
2026-08-13 6:37 ` [PATCH v7 07/10] PCI: dwc: Expose endpoint DMA resources Koichiro Den
` (4 subsequent siblings)
10 siblings, 1 reply; 25+ messages in thread
From: Koichiro Den @ 2026-08-13 6:37 UTC (permalink / raw)
To: Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Frank Li, Bjorn Helgaas, Jonathan Corbet,
Shuah Khan, Randy Dunlap, Vinod Koul, Jingoo Han,
Lorenzo Pieralisi, Rob Herring, Niklas Cassel, Damien Le Moal,
Arnd Bergmann
Cc: Marek Vasut, Yoshihiro Shimoda, linux-pci, linux-doc,
linux-kernel, dmaengine
Implement the EPC DMA channel delegation operations for DesignWare
endpoint controllers. Verify that the DMA engine channel reserved by the
endpoint function belongs to the integrated DesignWare eDMA instance,
then hand its interrupt routing to the host.
The DWC eDMA/HDMA engine generates DMA requests with a programmable
requester function number. For delegated channels, the host-side
dw-edma-pcie instance bound to the exposed DMA function programs its own
PCI_FUNC() into the per-channel requester field; the endpoint-side chip
func_no does
not participate in that handoff.
Reject VF requests because the RC-programmable DWC eDMA/HDMA register
window is assigned to a PF BAR only.
Reclaim returns interrupt routing to endpoint ownership. Propagate the
EPC quiesce request so bind failure paths can reclaim unexposed channels
without quiescing the DMA engine.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
Changes in v7:
- Delegate the DMA engine channel already reserved by the endpoint
function, matching the API and helper changes in patches 4 and 5.
.../pci/controller/dwc/pcie-designware-ep.c | 42 +++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 0b915824963a..a74d3896e436 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -858,6 +858,18 @@ dw_pcie_ep_find_bar_rsvd_region(struct dw_pcie_ep *ep,
return NULL;
}
+static int dw_pcie_ep_check_edma_vfunc(u8 vfunc_no)
+{
+ /*
+ * The DWC endpoint databook says it is not possible to assign the
+ * DMA/HDMA registers to any Virtual Function.
+ */
+ if (vfunc_no)
+ return -EOPNOTSUPP;
+
+ return 0;
+}
+
static int
dw_pcie_ep_get_aux_resources_count(struct pci_epc *epc, u8 func_no,
u8 vfunc_no)
@@ -933,6 +945,34 @@ dw_pcie_ep_get_aux_resources(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
return 0;
}
+static int dw_pcie_ep_delegate_dma_chan(struct pci_epc *epc, u8 func_no,
+ u8 vfunc_no, struct dma_chan *chan)
+{
+ 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;
+ int ret;
+
+ ret = dw_pcie_ep_check_edma_vfunc(vfunc_no);
+ if (ret)
+ return ret;
+
+ if (!edma->dw)
+ return -ENODEV;
+
+ if (!chan || chan->device->dev != edma->dev)
+ return -EINVAL;
+
+ return dw_edma_delegate_chan(chan);
+}
+
+static void dw_pcie_ep_reclaim_dma_chan(struct pci_epc *epc, u8 func_no,
+ u8 vfunc_no, struct dma_chan *chan,
+ bool quiesce)
+{
+ dw_edma_reclaim_chan(chan, quiesce);
+}
+
static const struct pci_epc_ops epc_ops = {
.write_header = dw_pcie_ep_write_header,
.set_bar = dw_pcie_ep_set_bar,
@@ -950,6 +990,8 @@ static const struct pci_epc_ops epc_ops = {
.get_features = dw_pcie_ep_get_features,
.get_aux_resources_count = dw_pcie_ep_get_aux_resources_count,
.get_aux_resources = dw_pcie_ep_get_aux_resources,
+ .delegate_dma_chan = dw_pcie_ep_delegate_dma_chan,
+ .reclaim_dma_chan = dw_pcie_ep_reclaim_dma_chan,
};
/**
--
2.51.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v7 06/10] PCI: dwc: Implement endpoint DMA channel delegation
2026-08-13 6:37 ` [PATCH v7 06/10] PCI: dwc: Implement endpoint DMA channel delegation Koichiro Den
@ 2026-08-13 6:47 ` sashiko-bot
0 siblings, 0 replies; 25+ messages in thread
From: sashiko-bot @ 2026-08-13 6:47 UTC (permalink / raw)
To: Koichiro Den; +Cc: vkoul, dmaengine, Frank.Li, linux-pci
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing validation in dw_pcie_ep_reclaim_dma_chan leading to unsafe downcast and bypass of VF restrictions
--
--- Patch [6]: [PATCH v7 06/10] PCI: dwc: Implement endpoint DMA channel delegation ---
commit ade184c0035acad80c032f5a61a7726af2557e6c
Author: Koichiro Den <den@valinux.co.jp>
PCI: dwc: Implement endpoint DMA channel delegation
Implement the EPC DMA channel delegation operations for DesignWare endpoint
controllers. Verify that the DMA engine channel reserved by the endpoint
function belongs to the integrated DesignWare eDMA instance, then hand its
interrupt routing to the host.
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
[ ... ]
> +static int dw_pcie_ep_delegate_dma_chan(struct pci_epc *epc, u8 func_no,
> + u8 vfunc_no, struct dma_chan *chan)
> +{
> + 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;
> + int ret;
> +
> + ret = dw_pcie_ep_check_edma_vfunc(vfunc_no);
> + if (ret)
> + return ret;
> +
> + if (!edma->dw)
> + return -ENODEV;
> +
> + if (!chan || chan->device->dev != edma->dev)
> + return -EINVAL;
> +
> + return dw_edma_delegate_chan(chan);
> +}
> +
> +static void dw_pcie_ep_reclaim_dma_chan(struct pci_epc *epc, u8 func_no,
> + u8 vfunc_no, struct dma_chan *chan,
> + bool quiesce)
> +{
> + dw_edma_reclaim_chan(chan, quiesce);
[Severity: High]
Should this function validate the channel owner and virtual function status
before passing it to dw_edma_reclaim_chan(), similar to the checks performed
in dw_pcie_ep_delegate_dma_chan()?
If an endpoint function driver calls this with a generic dma_chan from a
different DMA controller (for example, during error unwinding), couldn't
dw_edma_reclaim_chan() perform an unsafe downcast when it unconditionally
processes the pointer?
Additionally, omitting dw_pcie_ep_check_edma_vfunc() appears to allow virtual
functions to manipulate channels they are restricted from accessing during
delegation.
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813063757.3131865-1-den@valinux.co.jp?part=6
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v7 07/10] PCI: dwc: Expose endpoint DMA resources
2026-08-13 6:37 [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Koichiro Den
` (5 preceding siblings ...)
2026-08-13 6:37 ` [PATCH v7 06/10] PCI: dwc: Implement endpoint DMA channel delegation Koichiro Den
@ 2026-08-13 6:37 ` Koichiro Den
2026-08-13 6:45 ` sashiko-bot
2026-08-13 6:37 ` [PATCH v7 08/10] dmaengine: dw-edma-pcie: Discover endpoint DMA metadata Koichiro Den
` (3 subsequent siblings)
10 siblings, 1 reply; 25+ messages in thread
From: Koichiro Den @ 2026-08-13 6:37 UTC (permalink / raw)
To: Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Frank Li, Bjorn Helgaas, Jonathan Corbet,
Shuah Khan, Randy Dunlap, Vinod Koul, Jingoo Han,
Lorenzo Pieralisi, Rob Herring, Niklas Cassel, Damien Le Moal,
Arnd Bergmann
Cc: Marek Vasut, Yoshihiro Shimoda, linux-pci, linux-doc,
linux-kernel, dmaengine
Expose the DesignWare endpoint-integrated eDMA register window, logical
DMA channels, and linked-list descriptor memories through the EPC
auxiliary resource API. This lets endpoint functions decide which
channels to publish to the host.
When the DMA register window is already visible through a reserved BAR
region, report its BAR and offset. Otherwise report it as a normal
physical resource so an endpoint function can map it. DMA channel
resources carry hardware channel selectors, identify the corresponding
local DMA engine device and static channel ID, and refer to linked-list
descriptor memory by ID.
Expose DMA controller and channel resources only after the local DW eDMA
provider has been registered, and only expose channels whose linked-list
descriptor memory is available. The interrupt-emulation doorbell remains
reported when the local DW eDMA provider is registered and its offset is
valid, even if linked-list resources are unavailable. DWC non-LL exposure
needs a metadata ABI and host parser extension, so leave it unsupported
for now. Reject VF auxiliary resource queries because the
RC-programmable DWC eDMA/HDMA register window is assigned to a PF BAR
only.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
Changes in v7:
- Report the local DMA engine device and direction-flattened static
channel ID to match the auxiliary metadata changes in patch 3.
.../pci/controller/dwc/pcie-designware-ep.c | 142 +++++++++++++++++-
1 file changed, 134 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index a74d3896e436..957739b0ac51 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -858,6 +858,22 @@ dw_pcie_ep_find_bar_rsvd_region(struct dw_pcie_ep *ep,
return NULL;
}
+static bool dw_pcie_ep_has_edma_ll_resources(struct dw_edma_chip *edma,
+ u16 ll_wr_cnt, u16 ll_rd_cnt)
+{
+ unsigned int i;
+
+ for (i = 0; i < ll_wr_cnt; i++)
+ if (!edma->ll_region_wr[i].sz)
+ return false;
+
+ for (i = 0; i < ll_rd_cnt; i++)
+ if (!edma->ll_region_rd[i].sz)
+ return false;
+
+ return true;
+}
+
static int dw_pcie_ep_check_edma_vfunc(u8 vfunc_no)
{
/*
@@ -877,14 +893,30 @@ dw_pcie_ep_get_aux_resources_count(struct pci_epc *epc, u8 func_no,
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;
+ u16 ll_wr_cnt, ll_rd_cnt;
+ int count = 0;
+ int ret;
if (!pci->edma_reg_size)
return 0;
- if (edma->db_offset == ~0)
+ ret = dw_pcie_ep_check_edma_vfunc(vfunc_no);
+ if (ret)
+ return ret;
+
+ if (!edma->dw)
return 0;
- return 1;
+ ll_wr_cnt = edma->ll_wr_cnt;
+ ll_rd_cnt = edma->ll_rd_cnt;
+
+ if (dw_pcie_ep_has_edma_ll_resources(edma, ll_wr_cnt, ll_rd_cnt))
+ count += 1 + 2 * (ll_wr_cnt + ll_rd_cnt);
+
+ if (edma->db_offset != ~0)
+ count++;
+
+ return count;
}
static int
@@ -897,14 +929,34 @@ dw_pcie_ep_get_aux_resources(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
const struct pci_epc_bar_rsvd_region *rsvd;
struct dw_edma_chip *edma = &pci->edma;
enum pci_barno dma_ctrl_bar = NO_BAR;
- resource_size_t db_offset = edma->db_offset;
+ resource_size_t db_offset;
resource_size_t dma_ctrl_bar_offset = 0;
resource_size_t dma_reg_size;
- int count;
+ u16 ll_wr_cnt, ll_rd_cnt;
+ bool has_ll;
+ unsigned int i;
+ int count, ret;
- count = dw_pcie_ep_get_aux_resources_count(epc, func_no, vfunc_no);
- if (count < 0)
- return count;
+ if (!pci->edma_reg_size)
+ return 0;
+
+ ret = dw_pcie_ep_check_edma_vfunc(vfunc_no);
+ if (ret)
+ return ret;
+
+ if (!edma->dw)
+ return 0;
+
+ /* Keep the bounds check and fill on the same provider view. */
+ ll_wr_cnt = edma->ll_wr_cnt;
+ ll_rd_cnt = edma->ll_rd_cnt;
+ db_offset = edma->db_offset;
+ has_ll = dw_pcie_ep_has_edma_ll_resources(edma, ll_wr_cnt,
+ ll_rd_cnt);
+
+ count = db_offset != ~0;
+ if (has_ll)
+ count += 1 + 2 * (ll_wr_cnt + ll_rd_cnt);
if (num_resources < count)
return -ENOSPC;
@@ -921,6 +973,80 @@ dw_pcie_ep_get_aux_resources(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
if (rsvd && rsvd->size < dma_reg_size)
dma_reg_size = rsvd->size;
+ count = 0;
+ if (has_ll) {
+ resources[count++] = (struct pci_epc_aux_resource) {
+ .type = PCI_EPC_AUX_DMA_CTRL_MMIO,
+ .phys_addr = pci->edma_reg_phys,
+ .size = dma_reg_size,
+ .bar = dma_ctrl_bar,
+ .bar_offset = dma_ctrl_bar_offset,
+ .u.dma_ctrl = {
+ .reg_layout = PCI_EPC_AUX_DMA_REG_LAYOUT_DW_EDMA,
+ .reg_layout_data = edma->mf,
+ .ep_to_rc_ch_cnt = ll_wr_cnt,
+ .rc_to_ep_ch_cnt = ll_rd_cnt,
+ },
+ };
+
+ for (i = 0; i < ll_wr_cnt; i++) {
+ struct dw_edma_region *ll = &edma->ll_region_wr[i];
+ u16 desc_mem_id = i;
+
+ resources[count++] = (struct pci_epc_aux_resource) {
+ .type = PCI_EPC_AUX_DMA_CHAN,
+ .bar = NO_BAR,
+ .u.dma_chan = {
+ .dma_dev = edma->dev,
+ .chan_id = i,
+ .dir = PCI_EPC_AUX_DMA_EP_TO_RC,
+ .hw_ch = i,
+ .desc_mem_id = desc_mem_id,
+ },
+ };
+
+ resources[count++] = (struct pci_epc_aux_resource) {
+ .type = PCI_EPC_AUX_DMA_DESC_MEM,
+ .phys_addr = ll->paddr,
+ .size = ll->sz,
+ .bar = NO_BAR,
+ .u.dma_desc = {
+ .id = desc_mem_id,
+ },
+ };
+ }
+
+ for (i = 0; i < ll_rd_cnt; i++) {
+ struct dw_edma_region *ll = &edma->ll_region_rd[i];
+ u16 desc_mem_id = ll_wr_cnt + i;
+
+ resources[count++] = (struct pci_epc_aux_resource) {
+ .type = PCI_EPC_AUX_DMA_CHAN,
+ .bar = NO_BAR,
+ .u.dma_chan = {
+ .dma_dev = edma->dev,
+ .chan_id = ll_wr_cnt + i,
+ .dir = PCI_EPC_AUX_DMA_RC_TO_EP,
+ .hw_ch = i,
+ .desc_mem_id = desc_mem_id,
+ },
+ };
+
+ resources[count++] = (struct pci_epc_aux_resource) {
+ .type = PCI_EPC_AUX_DMA_DESC_MEM,
+ .phys_addr = ll->paddr,
+ .size = ll->sz,
+ .bar = NO_BAR,
+ .u.dma_desc = {
+ .id = desc_mem_id,
+ },
+ };
+ }
+ }
+
+ if (db_offset == ~0)
+ return 0;
+
/*
* For interrupt-emulation doorbells, report a standalone resource
* instead of bundling it into the DMA controller MMIO resource.
@@ -929,7 +1055,7 @@ dw_pcie_ep_get_aux_resources(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
sizeof(u32), dma_reg_size))
return -EINVAL;
- resources[0] = (struct pci_epc_aux_resource) {
+ resources[count] = (struct pci_epc_aux_resource) {
.type = PCI_EPC_AUX_DOORBELL_MMIO,
.phys_addr = pci->edma_reg_phys + db_offset,
.size = sizeof(u32),
--
2.51.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v7 07/10] PCI: dwc: Expose endpoint DMA resources
2026-08-13 6:37 ` [PATCH v7 07/10] PCI: dwc: Expose endpoint DMA resources Koichiro Den
@ 2026-08-13 6:45 ` sashiko-bot
0 siblings, 0 replies; 25+ messages in thread
From: sashiko-bot @ 2026-08-13 6:45 UTC (permalink / raw)
To: Koichiro Den; +Cc: vkoul, Frank.Li, dmaengine, linux-pci
> Expose the DesignWare endpoint-integrated eDMA register window, logical
> DMA channels, and linked-list descriptor memories through the EPC
> auxiliary resource API. This lets endpoint functions decide which
> channels to publish to the host.
>
> When the DMA register window is already visible through a reserved BAR
> region, report its BAR and offset. Otherwise report it as a normal
> physical resource so an endpoint function can map it. DMA channel
> resources carry hardware channel selectors, identify the corresponding
> local DMA engine device and static channel ID, and refer to linked-list
> descriptor memory by ID.
>
> Expose DMA controller and channel resources only after the local DW eDMA
> provider has been registered, and only expose channels whose linked-list
> descriptor memory is available. The interrupt-emulation doorbell remains
> reported when the local DW eDMA provider is registered and its offset is
> valid, even if linked-list resources are unavailable. DWC non-LL exposure
> needs a metadata ABI and host parser extension, so leave it unsupported
> for now. Reject VF auxiliary resource queries because the
> RC-programmable DWC eDMA/HDMA register window is assigned to a PF BAR
> only.
>
> Signed-off-by: Koichiro Den <den@valinux.co.jp>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813063757.3131865-1-den@valinux.co.jp?part=7
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v7 08/10] dmaengine: dw-edma-pcie: Discover endpoint DMA metadata
2026-08-13 6:37 [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Koichiro Den
` (6 preceding siblings ...)
2026-08-13 6:37 ` [PATCH v7 07/10] PCI: dwc: Expose endpoint DMA resources Koichiro Den
@ 2026-08-13 6:37 ` Koichiro Den
2026-08-13 6:50 ` sashiko-bot
2026-08-13 6:37 ` [PATCH v7 09/10] PCI: endpoint: Add DMA endpoint function Koichiro Den
` (2 subsequent siblings)
10 siblings, 1 reply; 25+ messages in thread
From: Koichiro Den @ 2026-08-13 6:37 UTC (permalink / raw)
To: Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Frank Li, Bjorn Helgaas, Jonathan Corbet,
Shuah Khan, Randy Dunlap, Vinod Koul, Jingoo Han,
Lorenzo Pieralisi, Rob Herring, Niklas Cassel, Damien Le Moal,
Arnd Bergmann
Cc: Marek Vasut, Yoshihiro Shimoda, linux-pci, linux-doc,
linux-kernel, dmaengine
Teach dw-edma-pcie to discover a PCI endpoint DMA function from
BAR-resident metadata. The metadata supplies the DMA register window,
channel counts, descriptor windows, optional auxiliary windows, and
endpoint-local descriptor and auxiliary addresses. Accept DesignWare
eDMA unroll, HDMA compatible, and HDMA native linked-list layouts.
Endpoint-provided DMA channels use raw slave addresses because the host
programs transfers against endpoint physical addresses, not PCI BAR
addresses. The host-side dw-edma-pcie instance is remote-routed by
default, so delegated channels report completions through IMWr/MSI.
Endpoint DMA metadata currently has no static PCI ID. Let an explicit
driver_override bind use the generic endpoint DMA metadata parser, but
do not treat arbitrary dynamic IDs without driver data as endpoint DMA
devices.
The endpoint polls HOST_REQ at a low idle rate before programming DMA
window submaps and setting READY. Let the host wait for several endpoint
poll periods before treating the READY handshake as timed out.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
Changes in v7:
- Write HOST_REQ through the dedicated host-request word introduced in
patch 2.
Note: This patch was previously posted as part of the separate part 3
series. No v6 of that series was sent.
drivers/dma/dw-edma/dw-edma-pcie.c | 394 ++++++++++++++++++++++++++++-
1 file changed, 392 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
index 9f237ba916de..bd5ed543fe98 100644
--- a/drivers/dma/dw-edma/dw-edma-pcie.c
+++ b/drivers/dma/dw-edma/dw-edma-pcie.c
@@ -11,9 +11,13 @@
#include <linux/pci.h>
#include <linux/device.h>
#include <linux/dma/edma.h>
+#include <linux/iopoll.h>
#include <linux/pci-epf.h>
#include <linux/msi.h>
#include <linux/bitfield.h>
+#include <linux/io.h>
+#include <linux/overflow.h>
+#include <linux/pci-ep-dma.h>
#include <linux/sizes.h>
#include "dw-edma-core.h"
@@ -45,6 +49,9 @@
#define DW_PCIE_XILINX_MDB_DT_OFF_GAP 0x100000
#define DW_PCIE_XILINX_MDB_DT_SIZE 0x800
+#define DW_PCIE_EP_DMA_READY_POLL_US 1000
+#define DW_PCIE_EP_DMA_READY_TIMEOUT_US 2000000
+
#define DW_BLOCK(a, b, c) \
{ \
.bar = a, \
@@ -94,6 +101,12 @@ struct dw_edma_pcie_match_data {
#define DW_EDMA_PCIE_F_DEVMEM_PHYS_OFF BIT(0)
#define DW_EDMA_PCIE_F_REG_OFFSET BIT(1)
+struct dw_edma_pcie_ep_dma_view {
+ struct pci_dev *pdev;
+ void __iomem *base;
+ resource_size_t limit;
+};
+
static const struct dw_edma_pcie_data snps_edda_data = {
/* eDMA registers location */
.rg.bar = BAR_0,
@@ -158,6 +171,13 @@ static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
.rd_ch_cnt = 8,
};
+static const struct dw_edma_pcie_data ep_dma_data = {
+ .mf = EDMA_MF_EDMA_UNROLL,
+ .irqs = EDMA_MAX_WR_CH + EDMA_MAX_RD_CH,
+ .wr_ch_cnt = EDMA_MAX_WR_CH,
+ .rd_ch_cnt = EDMA_MAX_RD_CH,
+};
+
static void dw_edma_set_chan_region_offset(struct dw_edma_pcie_data *pdata,
enum pci_barno bar, off_t start_off,
off_t ll_off_gap, size_t ll_size,
@@ -227,6 +247,92 @@ static const struct dw_edma_plat_ops dw_edma_pcie_plat_ops = {
.pci_address = dw_edma_pcie_address,
};
+static const struct dw_edma_plat_ops dw_edma_pcie_raw_addr_plat_ops = {
+ .irq_vector = dw_edma_pcie_irq_vector,
+};
+
+static bool dw_edma_pcie_valid_bar(enum pci_barno bar)
+{
+ return bar >= BAR_0 && bar <= BAR_5;
+}
+
+static bool dw_edma_pcie_valid_bar_range(struct pci_dev *pdev,
+ enum pci_barno bar, u64 off,
+ size_t sz)
+{
+ resource_size_t bar_len;
+
+ if (!dw_edma_pcie_valid_bar(bar) || !sz)
+ return false;
+
+ bar_len = pci_resource_len(pdev, bar);
+
+ return off <= bar_len && sz <= bar_len - off;
+}
+
+static bool dw_edma_pcie_valid_block(struct pci_dev *pdev,
+ const struct dw_edma_block *block)
+{
+ return dw_edma_pcie_valid_bar_range(pdev, block->bar, block->off,
+ block->sz);
+}
+
+static bool dw_edma_pcie_ep_dma_bar_scannable(struct pci_dev *pdev,
+ enum pci_barno bar)
+{
+ unsigned long flags = pci_resource_flags(pdev, bar);
+
+ if (!(flags & IORESOURCE_MEM))
+ return false;
+
+ if (flags & (IORESOURCE_UNSET | IORESOURCE_DISABLED))
+ return false;
+
+ return pci_resource_len(pdev, bar) >= PCI_EP_DMA_METADATA_HDR_LEN;
+}
+
+static u32 dw_edma_pcie_ep_dma_readl(struct dw_edma_pcie_ep_dma_view *view,
+ u16 off)
+{
+ return readl(view->base + off);
+}
+
+static void dw_edma_pcie_ep_dma_writel(struct dw_edma_pcie_ep_dma_view *view,
+ u16 off, u32 val)
+{
+ writel(val, view->base + off);
+}
+
+static void
+dw_edma_pcie_ep_dma_clear_host_req(struct dw_edma_pcie_ep_dma_view *view)
+{
+ dw_edma_pcie_ep_dma_writel(view, PCI_EP_DMA_METADATA_HOST_CTRL, 0);
+}
+
+static u64 dw_edma_pcie_ep_dma_read64(struct dw_edma_pcie_ep_dma_view *view,
+ u16 lo, u16 hi)
+{
+ u64 val;
+
+ val = dw_edma_pcie_ep_dma_readl(view, hi);
+
+ return (val << 32) | dw_edma_pcie_ep_dma_readl(view, lo);
+}
+
+static int dw_edma_pcie_ep_dma_read_off(struct dw_edma_pcie_ep_dma_view *view,
+ u16 lo, u16 hi, off_t *off)
+{
+ u64 val;
+
+ val = dw_edma_pcie_ep_dma_read64(view, lo, hi);
+ if (val > type_max(*off))
+ return -EINVAL;
+
+ *off = val;
+
+ return 0;
+}
+
static void dw_edma_pcie_get_synopsys_dma_data(struct pci_dev *pdev,
struct dw_edma_pcie_data *pdata)
{
@@ -328,6 +434,270 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
pdata->devmem_phys_off = off;
}
+static int
+dw_edma_pcie_parse_ep_dma_ch_table(struct dw_edma_pcie_ep_dma_view *view,
+ struct dw_edma_pcie_data *pdata,
+ u16 table_off, u16 entry_size, u16 ch_cnt,
+ bool write)
+{
+ struct dw_edma_block *desc_blocks = write ? pdata->ll_wr : pdata->ll_rd;
+ struct dw_edma_block *data_blocks = write ? pdata->dt_wr : pdata->dt_rd;
+ u32 ctrl;
+ u16 i;
+ int ret;
+
+ for (i = 0; i < ch_cnt; i++) {
+ struct dw_edma_block *desc_block = &desc_blocks[i];
+ struct dw_edma_block *data_block = &data_blocks[i];
+ u16 off = table_off + i * entry_size;
+ u16 field, lo, hi;
+
+ field = off + PCI_EP_DMA_METADATA_CH_CTRL;
+ ctrl = dw_edma_pcie_ep_dma_readl(view, field);
+ if (FIELD_GET(PCI_EP_DMA_METADATA_CH_CTRL_HW_CH, ctrl) != i)
+ return -EOPNOTSUPP;
+
+ desc_block->bar =
+ FIELD_GET(PCI_EP_DMA_METADATA_CH_CTRL_DESC_BAR, ctrl);
+ lo = off + PCI_EP_DMA_METADATA_CH_DESC_OFF_LO;
+ hi = off + PCI_EP_DMA_METADATA_CH_DESC_OFF_HI;
+ ret = dw_edma_pcie_ep_dma_read_off(view, lo, hi,
+ &desc_block->off);
+ if (ret)
+ return ret;
+ field = off + PCI_EP_DMA_METADATA_CH_DESC_SIZE;
+ desc_block->sz = dw_edma_pcie_ep_dma_readl(view, field);
+ lo = off + PCI_EP_DMA_METADATA_CH_DESC_ADDR_LO;
+ hi = off + PCI_EP_DMA_METADATA_CH_DESC_ADDR_HI;
+ desc_block->paddr =
+ dw_edma_pcie_ep_dma_read64(view, lo, hi);
+ desc_block->paddr_valid = true;
+ if (!dw_edma_pcie_valid_block(view->pdev, desc_block))
+ return -EINVAL;
+
+ *data_block = (struct dw_edma_block) { .bar = NO_BAR };
+ if (!(ctrl & PCI_EP_DMA_METADATA_CH_CTRL_AUX_VALID))
+ continue;
+
+ data_block->bar =
+ FIELD_GET(PCI_EP_DMA_METADATA_CH_CTRL_AUX_BAR, ctrl);
+ lo = off + PCI_EP_DMA_METADATA_CH_AUX_OFF_LO;
+ hi = off + PCI_EP_DMA_METADATA_CH_AUX_OFF_HI;
+ ret = dw_edma_pcie_ep_dma_read_off(view, lo, hi,
+ &data_block->off);
+ if (ret)
+ return ret;
+ field = off + PCI_EP_DMA_METADATA_CH_AUX_SIZE;
+ data_block->sz = dw_edma_pcie_ep_dma_readl(view, field);
+ lo = off + PCI_EP_DMA_METADATA_CH_AUX_ADDR_LO;
+ hi = off + PCI_EP_DMA_METADATA_CH_AUX_ADDR_HI;
+ data_block->paddr =
+ dw_edma_pcie_ep_dma_read64(view, lo, hi);
+ data_block->paddr_valid = true;
+ if (!dw_edma_pcie_valid_block(view->pdev, data_block))
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int
+dw_edma_pcie_ep_dma_wait_ready(struct dw_edma_pcie_ep_dma_view *view)
+{
+ u32 val;
+
+ /*
+ * The host cannot build a usable eDMA instance until the endpoint has
+ * pinned and published the channel submaps, so keep the handshake
+ * synchronous and bounded during probe.
+ */
+ return read_poll_timeout(dw_edma_pcie_ep_dma_readl, val,
+ val & PCI_EP_DMA_METADATA_CTRL_READY,
+ DW_PCIE_EP_DMA_READY_POLL_US,
+ DW_PCIE_EP_DMA_READY_TIMEOUT_US, false,
+ view, PCI_EP_DMA_METADATA_CTRL);
+}
+
+static int
+dw_edma_pcie_validate_ep_dma_metadata(struct dw_edma_pcie_ep_dma_view *view,
+ u32 *metadata_ctrl, u8 *reg_layout_data)
+{
+ size_t table_size, table_end;
+ enum pci_barno reg_bar;
+ u16 len, entry_size;
+ u16 wr_ch_cnt, rd_ch_cnt;
+ u8 layout, layout_data;
+ u32 val;
+
+ val = dw_edma_pcie_ep_dma_readl(view, 0);
+ if (val != PCI_EP_DMA_METADATA_MAGIC)
+ return -ENODEV;
+
+ val = dw_edma_pcie_ep_dma_readl(view, PCI_EP_DMA_METADATA_HDR);
+ if (FIELD_GET(PCI_EP_DMA_METADATA_HDR_REV, val) !=
+ PCI_EP_DMA_METADATA_REV)
+ return -EINVAL;
+
+ len = FIELD_GET(PCI_EP_DMA_METADATA_HDR_LEN_FIELD, val);
+ if (len < PCI_EP_DMA_METADATA_HDR_LEN)
+ return -EINVAL;
+ if (len > view->limit)
+ return -EINVAL;
+
+ val = dw_edma_pcie_ep_dma_readl(view, PCI_EP_DMA_METADATA_REG_LAYOUT);
+ layout = FIELD_GET(PCI_EP_DMA_METADATA_REG_LAYOUT_ID, val);
+ if (layout != PCI_EP_DMA_METADATA_REG_LAYOUT_DW_EDMA)
+ return -EOPNOTSUPP;
+
+ layout_data = FIELD_GET(PCI_EP_DMA_METADATA_REG_LAYOUT_DATA, val);
+ if (layout_data == EDMA_MF_EDMA_LEGACY)
+ return -EOPNOTSUPP;
+ if (layout_data != EDMA_MF_EDMA_UNROLL &&
+ layout_data != EDMA_MF_HDMA_COMPAT &&
+ layout_data != EDMA_MF_HDMA_NATIVE)
+ return -EINVAL;
+
+ val = dw_edma_pcie_ep_dma_readl(view, PCI_EP_DMA_METADATA_CTRL);
+ reg_bar = FIELD_GET(PCI_EP_DMA_METADATA_CTRL_REG_BAR, val);
+ if (!dw_edma_pcie_valid_bar(reg_bar))
+ return -EINVAL;
+
+ wr_ch_cnt = FIELD_GET(PCI_EP_DMA_METADATA_CTRL_WR_CH_COUNT, val);
+ rd_ch_cnt = FIELD_GET(PCI_EP_DMA_METADATA_CTRL_RD_CH_COUNT, val);
+ if (!wr_ch_cnt && !rd_ch_cnt)
+ return -EINVAL;
+ if (wr_ch_cnt > EDMA_MAX_WR_CH || rd_ch_cnt > EDMA_MAX_RD_CH)
+ return -EINVAL;
+
+ entry_size = FIELD_GET(PCI_EP_DMA_METADATA_CTRL_CH_ENTRY_SIZE, val);
+ if (entry_size < PCI_EP_DMA_METADATA_CH_ENTRY_SIZE ||
+ entry_size % sizeof(u32))
+ return -EINVAL;
+
+ if (check_mul_overflow((size_t)(wr_ch_cnt + rd_ch_cnt),
+ (size_t)entry_size, &table_size) ||
+ check_add_overflow((size_t)PCI_EP_DMA_METADATA_HDR_LEN,
+ table_size, &table_end) ||
+ table_end > len)
+ return -EINVAL;
+
+ if (metadata_ctrl)
+ *metadata_ctrl = val;
+ if (reg_layout_data)
+ *reg_layout_data = layout_data;
+
+ return 0;
+}
+
+static int
+dw_edma_pcie_parse_ep_dma_data(struct dw_edma_pcie_ep_dma_view *view,
+ struct dw_edma_pcie_data *pdata)
+{
+ u32 ctrl, reg_sz;
+ u8 reg_layout_data;
+ u64 reg_off;
+ u16 wr_table, rd_table, entry_size;
+ u16 wr_ch_cnt, rd_ch_cnt;
+ int ret;
+
+ ret = dw_edma_pcie_validate_ep_dma_metadata(view, &ctrl,
+ ®_layout_data);
+ if (ret)
+ return ret;
+
+ pci_dbg(view->pdev, "Detected PCI endpoint DMA BAR metadata\n");
+
+ pdata->mf = reg_layout_data;
+ pdata->rg.bar = FIELD_GET(PCI_EP_DMA_METADATA_CTRL_REG_BAR, ctrl);
+
+ wr_ch_cnt = FIELD_GET(PCI_EP_DMA_METADATA_CTRL_WR_CH_COUNT, ctrl);
+ rd_ch_cnt = FIELD_GET(PCI_EP_DMA_METADATA_CTRL_RD_CH_COUNT, ctrl);
+ pdata->wr_ch_cnt = min_t(u16, pdata->wr_ch_cnt, wr_ch_cnt);
+ pdata->rd_ch_cnt = min_t(u16, pdata->rd_ch_cnt, rd_ch_cnt);
+ pdata->irqs = pdata->wr_ch_cnt + pdata->rd_ch_cnt;
+ reg_off = dw_edma_pcie_ep_dma_read64(view,
+ PCI_EP_DMA_METADATA_REG_OFF_LO,
+ PCI_EP_DMA_METADATA_REG_OFF_HI);
+ reg_sz = dw_edma_pcie_ep_dma_readl(view, PCI_EP_DMA_METADATA_REG_SIZE);
+ if (reg_off > type_max(pdata->rg.off) ||
+ !dw_edma_pcie_valid_bar_range(view->pdev, pdata->rg.bar,
+ reg_off, reg_sz))
+ return -EINVAL;
+ pdata->rg.off = reg_off;
+ pdata->rg.sz = reg_sz;
+
+ entry_size = FIELD_GET(PCI_EP_DMA_METADATA_CTRL_CH_ENTRY_SIZE, ctrl);
+ wr_table = PCI_EP_DMA_METADATA_HDR_LEN;
+ rd_table = PCI_EP_DMA_METADATA_HDR_LEN + wr_ch_cnt * entry_size;
+
+ ret = dw_edma_pcie_parse_ep_dma_ch_table(view, pdata, wr_table,
+ entry_size, pdata->wr_ch_cnt,
+ true);
+ if (ret)
+ return ret;
+
+ return dw_edma_pcie_parse_ep_dma_ch_table(view, pdata, rd_table,
+ entry_size,
+ pdata->rd_ch_cnt, false);
+}
+
+static int
+dw_edma_pcie_parse_ep_dma_caps(struct pci_dev *pdev,
+ struct dw_edma_pcie_data *pdata)
+{
+ struct dw_edma_pcie_ep_dma_view metadata_view;
+ void __iomem *base;
+ resource_size_t bar_len;
+ enum pci_barno bar;
+ int ret;
+
+ for (bar = BAR_0; bar < PCI_STD_NUM_BARS; bar++) {
+ if (!dw_edma_pcie_ep_dma_bar_scannable(pdev, bar))
+ continue;
+
+ bar_len = pci_resource_len(pdev, bar);
+ base = pci_iomap_range(pdev, bar, 0, 0);
+ if (!base)
+ continue;
+
+ metadata_view = (struct dw_edma_pcie_ep_dma_view) {
+ .pdev = pdev,
+ .base = base,
+ .limit = bar_len,
+ };
+ ret = dw_edma_pcie_validate_ep_dma_metadata(&metadata_view,
+ NULL, NULL);
+ if (ret == -ENODEV) {
+ pci_iounmap(metadata_view.pdev, base);
+ continue;
+ }
+ if (ret) {
+ pci_iounmap(metadata_view.pdev, base);
+ return ret;
+ }
+
+ dw_edma_pcie_ep_dma_writel(&metadata_view,
+ PCI_EP_DMA_METADATA_HOST_CTRL,
+ PCI_EP_DMA_METADATA_HOST_CTRL_REQ);
+
+ ret = dw_edma_pcie_ep_dma_wait_ready(&metadata_view);
+ if (ret) {
+ dw_edma_pcie_ep_dma_clear_host_req(&metadata_view);
+ pci_iounmap(metadata_view.pdev, base);
+ return ret;
+ }
+
+ ret = dw_edma_pcie_parse_ep_dma_data(&metadata_view, pdata);
+ if (ret)
+ dw_edma_pcie_ep_dma_clear_host_req(&metadata_view);
+ pci_iounmap(metadata_view.pdev, base);
+
+ return ret;
+ }
+
+ return -ENODEV;
+}
+
static int
dw_edma_pcie_parse_synopsys_caps(struct pci_dev *pdev,
struct dw_edma_pcie_data *pdata)
@@ -367,6 +737,14 @@ dw_edma_pcie_parse_xilinx_caps(struct pci_dev *pdev,
return 0;
}
+static const struct dw_edma_pcie_match_data ep_dma_match_data = {
+ .data = &ep_dma_data,
+ .plat_ops = &dw_edma_pcie_raw_addr_plat_ops,
+ .parse_caps = dw_edma_pcie_parse_ep_dma_caps,
+ .flags = DW_EDMA_PCIE_F_REG_OFFSET,
+ .chip_flags = DW_EDMA_CHIP_PARTIAL,
+};
+
static u64 dw_edma_get_phys_addr(struct pci_dev *pdev,
const struct dw_edma_pcie_match_data *match,
struct dw_edma_pcie_data *pdata,
@@ -400,8 +778,17 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
int err, nr_irqs;
int i, mask;
- if (!match)
- return -ENODEV;
+ if (!match) {
+ /*
+ * The endpoint DMA metadata path has no static PCI ID yet.
+ * Accept it only for an explicit driver_override bind, not for
+ * arbitrary dynamic IDs without driver data.
+ */
+ if (!device_has_driver_override(&pdev->dev))
+ return -ENODEV;
+
+ match = &ep_dma_match_data;
+ }
pdata = match->data;
if (!pdata)
@@ -659,6 +1046,9 @@ static struct pci_driver dw_edma_pcie_driver = {
.id_table = dw_edma_pcie_id_table,
.probe = dw_edma_pcie_probe,
.remove = dw_edma_pcie_remove,
+ .driver = {
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ },
};
module_pci_driver(dw_edma_pcie_driver);
--
2.51.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v7 08/10] dmaengine: dw-edma-pcie: Discover endpoint DMA metadata
2026-08-13 6:37 ` [PATCH v7 08/10] dmaengine: dw-edma-pcie: Discover endpoint DMA metadata Koichiro Den
@ 2026-08-13 6:50 ` sashiko-bot
0 siblings, 0 replies; 25+ messages in thread
From: sashiko-bot @ 2026-08-13 6:50 UTC (permalink / raw)
To: Koichiro Den; +Cc: Frank.Li, vkoul, dmaengine, linux-pci
> Teach dw-edma-pcie to discover a PCI endpoint DMA function from
> BAR-resident metadata. The metadata supplies the DMA register window,
> channel counts, descriptor windows, optional auxiliary windows, and
> endpoint-local descriptor and auxiliary addresses. Accept DesignWare
> eDMA unroll, HDMA compatible, and HDMA native linked-list layouts.
>
> Endpoint-provided DMA channels use raw slave addresses because the host
> programs transfers against endpoint physical addresses, not PCI BAR
> addresses. The host-side dw-edma-pcie instance is remote-routed by
> default, so delegated channels report completions through IMWr/MSI.
>
> Endpoint DMA metadata currently has no static PCI ID. Let an explicit
> driver_override bind use the generic endpoint DMA metadata parser, but
> do not treat arbitrary dynamic IDs without driver data as endpoint DMA
> devices.
>
> The endpoint polls HOST_REQ at a low idle rate before programming DMA
> window submaps and setting READY. Let the host wait for several endpoint
> poll periods before treating the READY handshake as timed out.
>
> Signed-off-by: Koichiro Den <den@valinux.co.jp>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813063757.3131865-1-den@valinux.co.jp?part=8
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v7 09/10] PCI: endpoint: Add DMA endpoint function
2026-08-13 6:37 [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Koichiro Den
` (7 preceding siblings ...)
2026-08-13 6:37 ` [PATCH v7 08/10] dmaengine: dw-edma-pcie: Discover endpoint DMA metadata Koichiro Den
@ 2026-08-13 6:37 ` Koichiro Den
2026-08-13 6:53 ` sashiko-bot
2026-08-13 6:37 ` [PATCH v7 10/10] Documentation: PCI: Add PCI DMA endpoint function documentation Koichiro Den
2026-08-13 11:46 ` [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Niklas Cassel
10 siblings, 1 reply; 25+ messages in thread
From: Koichiro Den @ 2026-08-13 6:37 UTC (permalink / raw)
To: Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Frank Li, Bjorn Helgaas, Jonathan Corbet,
Shuah Khan, Randy Dunlap, Vinod Koul, Jingoo Han,
Lorenzo Pieralisi, Rob Herring, Niklas Cassel, Damien Le Moal,
Arnd Bergmann
Cc: Marek Vasut, Yoshihiro Shimoda, linux-pci, linux-doc,
linux-kernel, dmaengine
Add pci-epf-dma, an endpoint function that exposes selected
endpoint-integrated DMA channels as a separate PCI DMA controller
function.
The function consumes EPC auxiliary DMA channel and descriptor memory
resources, reserves exact local channels through dmaengine, delegates
their hardware programming ownership through the EPC DMA channel
delegation API, publishes a stable metadata BAR for host discovery, and
uses a DMA window BAR for DMA resources that are not already host-visible.
For DesignWare eDMA unroll and HDMA compatible layouts, channel delegation
is constrained to whole directions. HDMA native linked-list mode uses
per-channel registers and can delegate a dense channel prefix without
taking the whole direction.
After the host-side driver finds the metadata and requests the final
layout, the endpoint function programs DMA window BAR submaps and marks
the metadata ready. If the link drops after the host request is set,
clear only the ready bit and retry submap programming on the next
link-up without requiring the host driver to probe again.
If setup fails before the metadata is marked ready, reclaim any
delegated channels without asking the EPC backend to quiesce them, then
release the local dmaengine reservations. Once the ready bit has been
set, teardown requests quiesce because the host may have programmed the
exposed DMA windows. Shared-register directions are quiesced on the
first channel reclaim; the remaining channels are reclaimed without
repeating the direction-wide quiesce.
The endpoint function does not bake in a vendor/device ID. As with other
generic endpoint functions, users provide the PCI IDs through the common
EPF configfs header attributes.
Suggested-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
Changes in v7:
- Reserve exact channels through dmaengine before passing them to the EPC
delegation API, per discussion with Frank on v6 patch 4.
- Add the resulting DMA_ENGINE dependency.
- Read HOST_REQ from the dedicated host-request word introduced in
patch 2.
- Restore auto-selected BARs to the unset state after freeing the layout.
Note: This patch was previously posted as part of the separate part 3
series. No v6 of that series was sent.
drivers/pci/endpoint/functions/Kconfig | 13 +
drivers/pci/endpoint/functions/Makefile | 1 +
drivers/pci/endpoint/functions/pci-epf-dma.c | 1577 ++++++++++++++++++
3 files changed, 1591 insertions(+)
create mode 100644 drivers/pci/endpoint/functions/pci-epf-dma.c
diff --git a/drivers/pci/endpoint/functions/Kconfig b/drivers/pci/endpoint/functions/Kconfig
index bb5a23994288..736e9c719236 100644
--- a/drivers/pci/endpoint/functions/Kconfig
+++ b/drivers/pci/endpoint/functions/Kconfig
@@ -39,6 +39,19 @@ config PCI_EPF_VNTB
If in doubt, say "N" to disable Endpoint NTB driver.
+config PCI_EPF_DMA
+ tristate "PCI Endpoint DMA driver"
+ depends on PCI_ENDPOINT && DMA_ENGINE
+ select CONFIGFS_FS
+ help
+ Select this configuration option to expose an endpoint-integrated
+ DMA controller as a PCI endpoint function. The function advertises
+ the DMA controller layout to the host using BAR-resident metadata
+ and maps resources that are not already host-visible into the
+ DMA window BAR.
+
+ If in doubt, say "N" to disable Endpoint DMA driver.
+
config PCI_EPF_MHI
tristate "PCI Endpoint driver for MHI bus"
depends on PCI_ENDPOINT && MHI_BUS_EP
diff --git a/drivers/pci/endpoint/functions/Makefile b/drivers/pci/endpoint/functions/Makefile
index 696473fce50e..de92f6897b8f 100644
--- a/drivers/pci/endpoint/functions/Makefile
+++ b/drivers/pci/endpoint/functions/Makefile
@@ -6,4 +6,5 @@
obj-$(CONFIG_PCI_EPF_TEST) += pci-epf-test.o
obj-$(CONFIG_PCI_EPF_NTB) += pci-epf-ntb.o
obj-$(CONFIG_PCI_EPF_VNTB) += pci-epf-vntb.o
+obj-$(CONFIG_PCI_EPF_DMA) += pci-epf-dma.o
obj-$(CONFIG_PCI_EPF_MHI) += pci-epf-mhi.o
diff --git a/drivers/pci/endpoint/functions/pci-epf-dma.c b/drivers/pci/endpoint/functions/pci-epf-dma.c
new file mode 100644
index 000000000000..7e1c3e184a06
--- /dev/null
+++ b/drivers/pci/endpoint/functions/pci-epf-dma.c
@@ -0,0 +1,1577 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PCI endpoint function that exposes an endpoint-integrated DMA controller
+ * to the PCI host.
+ *
+ * The host-side dw-edma-pcie driver consumes the BAR metadata published
+ * by this function.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/configfs.h>
+#include <linux/dma/edma.h>
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
+#include <linux/module.h>
+#include <linux/overflow.h>
+#include <linux/pci-ep-dma.h>
+#include <linux/pci-epc.h>
+#include <linux/pci-epf.h>
+#include <linux/pci_regs.h>
+#include <linux/slab.h>
+#include <linux/workqueue.h>
+
+/* HOST_REQ is set by the host driver, so poll it at a low idle rate. */
+#define PCI_EPF_DMA_HOST_REQ_POLL_MS 500
+
+struct pci_epf_dma_bar_map {
+ const struct pci_epc_aux_resource *res;
+ enum pci_barno bar;
+ u64 res_offset_in_bar;
+ u64 submap_offset_in_bar;
+ dma_addr_t phys_addr;
+ dma_addr_t dma_addr;
+ size_t map_size;
+ bool needs_submap;
+ bool dma_mapped;
+};
+
+struct pci_epf_dma {
+ struct pci_epf *epf;
+ struct config_group group;
+ struct delayed_work map_work;
+
+ enum pci_barno metadata_bar;
+ enum pci_barno dma_window_bar;
+ bool metadata_bar_auto;
+ bool dma_window_bar_auto;
+ u16 wr_chans;
+ u16 rd_chans;
+ u8 reg_layout;
+ u8 reg_layout_data;
+
+ /*
+ * Backing storage for ctrl, channel and descriptor resource pointers.
+ * DesignWare eDMA is the only exposed layout today, so EDMA_MAX_* is
+ * the per-direction bound for these arrays.
+ */
+ struct pci_epc_aux_resource *resources;
+ unsigned int num_resources;
+ const struct pci_epc_aux_resource *ctrl;
+ const struct pci_epc_aux_resource *ep_to_rc_aux_chan[EDMA_MAX_WR_CH];
+ const struct pci_epc_aux_resource *rc_to_ep_aux_chan[EDMA_MAX_RD_CH];
+ const struct pci_epc_aux_resource *ep_to_rc_desc[EDMA_MAX_WR_CH];
+ const struct pci_epc_aux_resource *rc_to_ep_desc[EDMA_MAX_RD_CH];
+
+ /* Local DMA engine reservations for channels delegated to the host. */
+ struct dma_chan *ep_to_rc_chan[EDMA_MAX_WR_CH];
+ struct dma_chan *rc_to_ep_chan[EDMA_MAX_RD_CH];
+
+ void *metadata_addr;
+ void *dma_window_addr;
+ size_t msix_table_offset;
+ struct pci_epf_dma_bar_map *bar_maps;
+ unsigned int num_bar_maps;
+ struct pci_epf_bar_submap *submaps;
+ unsigned int num_submaps;
+
+ /* Cleared when a later event should retry programming the submaps. */
+ bool submaps_programmed;
+ bool channels_exposed;
+};
+
+#define to_epf_dma(epf_group) container_of((epf_group), struct pci_epf_dma, group)
+
+static struct pci_epf_header pci_epf_dma_header = {
+ .vendorid = PCI_ANY_ID,
+ .deviceid = PCI_ANY_ID,
+ .baseclass_code = PCI_BASE_CLASS_SYSTEM,
+ .subclass_code = PCI_CLASS_SYSTEM_DMA & 0xff,
+ .interrupt_pin = PCI_INTERRUPT_INTA,
+};
+
+static void
+pci_epf_dma_release_direction(struct pci_epf_dma *epf_dma,
+ struct dma_chan **chans,
+ unsigned int count, bool quiesce, bool shared)
+{
+ struct pci_epf *epf = epf_dma->epf;
+ unsigned int i;
+
+ for (i = 0; i < count; i++) {
+ if (!chans[i])
+ continue;
+
+ pci_epc_reclaim_dma_chan(epf->epc, epf->func_no, epf->vfunc_no,
+ chans[i], quiesce);
+ dma_release_channel(chans[i]);
+ chans[i] = NULL;
+
+ /* One quiesce covers the whole shared direction. */
+ if (shared)
+ quiesce = false;
+ }
+}
+
+static void pci_epf_dma_release_channels(struct pci_epf_dma *epf_dma)
+{
+ bool shared;
+
+ shared = epf_dma->reg_layout == PCI_EP_DMA_METADATA_REG_LAYOUT_DW_EDMA &&
+ (epf_dma->reg_layout_data == EDMA_MF_EDMA_UNROLL ||
+ epf_dma->reg_layout_data == EDMA_MF_HDMA_COMPAT);
+
+ pci_epf_dma_release_direction(epf_dma, epf_dma->ep_to_rc_chan,
+ ARRAY_SIZE(epf_dma->ep_to_rc_chan),
+ epf_dma->channels_exposed, shared);
+ pci_epf_dma_release_direction(epf_dma, epf_dma->rc_to_ep_chan,
+ ARRAY_SIZE(epf_dma->rc_to_ep_chan),
+ epf_dma->channels_exposed, shared);
+
+ epf_dma->channels_exposed = false;
+}
+
+struct pci_epf_dma_filter_args {
+ struct device *dma_dev;
+ int chan_id;
+};
+
+static bool pci_epf_dma_filter_chan(struct dma_chan *chan, void *data)
+{
+ struct pci_epf_dma_filter_args *filter = data;
+
+ return chan->device->dev == filter->dma_dev &&
+ chan->chan_id == filter->chan_id;
+}
+
+static int pci_epf_dma_claim_channel(struct pci_epf_dma *epf_dma,
+ const struct pci_epc_aux_resource *res,
+ struct dma_chan **chan)
+{
+ struct pci_epf_dma_filter_args filter = {
+ .dma_dev = res->u.dma_chan.dma_dev,
+ .chan_id = res->u.dma_chan.chan_id,
+ };
+ struct pci_epf *epf = epf_dma->epf;
+ struct device *dev = &epf_dma->epf->dev;
+ struct dma_chan *dchan;
+ dma_cap_mask_t mask;
+ int ret;
+
+ if (!filter.dma_dev || filter.chan_id < 0)
+ return -EINVAL;
+
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_SLAVE, mask);
+
+ dchan = dma_request_channel(mask, pci_epf_dma_filter_chan, &filter);
+ if (!dchan) {
+ dev_err(dev, "DMA channel %u is unavailable\n",
+ res->u.dma_chan.hw_ch);
+ return -EBUSY;
+ }
+
+ ret = pci_epc_delegate_dma_chan(epf->epc, epf->func_no, epf->vfunc_no,
+ dchan);
+ if (ret) {
+ dev_err(dev, "DMA channel %u cannot be delegated\n",
+ res->u.dma_chan.hw_ch);
+ dma_release_channel(dchan);
+ return ret;
+ }
+
+ *chan = dchan;
+
+ return 0;
+}
+
+static int
+pci_epf_dma_validate_dw_edma_ctrl(struct pci_epf_dma *epf_dma,
+ const struct pci_epc_aux_resource *ctrl)
+{
+ struct device *dev = &epf_dma->epf->dev;
+ enum dw_edma_map_format map = ctrl->u.dma_ctrl.reg_layout_data;
+ u16 total_wr_chans = ctrl->u.dma_ctrl.ep_to_rc_ch_cnt;
+ u16 total_rd_chans = ctrl->u.dma_ctrl.rc_to_ep_ch_cnt;
+
+ switch (map) {
+ case EDMA_MF_EDMA_LEGACY:
+ dev_err(dev, "legacy DesignWare eDMA layout cannot be delegated\n");
+ return -EOPNOTSUPP;
+ case EDMA_MF_EDMA_UNROLL:
+ case EDMA_MF_HDMA_COMPAT:
+ /*
+ * The unrolled eDMA and HDMA compatibility maps share control
+ * across each direction, so do not split one direction between
+ * the endpoint and the host.
+ */
+ if ((epf_dma->wr_chans && epf_dma->wr_chans != total_wr_chans) ||
+ (epf_dma->rd_chans && epf_dma->rd_chans != total_rd_chans)) {
+ dev_err(dev, "DesignWare shared-register DMA delegation must cover the whole direction\n");
+ return -EOPNOTSUPP;
+ }
+ return 0;
+ case EDMA_MF_HDMA_NATIVE:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static bool pci_epf_dma_bar_usable(const struct pci_epc_features *epc_features,
+ enum pci_barno bar)
+{
+ if (bar < BAR_0 || bar >= PCI_STD_NUM_BARS)
+ return false;
+
+ return epc_features->bar[bar].type != BAR_RESERVED &&
+ epc_features->bar[bar].type != BAR_DISABLED;
+}
+
+static bool pci_epf_dma_bar_has_fixed_resource(struct pci_epf_dma *epf_dma,
+ enum pci_barno bar)
+{
+ unsigned int i;
+
+ for (i = 0; i < epf_dma->num_resources; i++) {
+ if (epf_dma->resources[i].bar == bar)
+ return true;
+ }
+
+ return false;
+}
+
+static enum pci_barno
+pci_epf_dma_first_usable_bar(struct pci_epf_dma *epf_dma,
+ const struct pci_epc_features *epc_features,
+ enum pci_barno exclude)
+{
+ enum pci_barno bar;
+
+ for (bar = BAR_0; bar < PCI_STD_NUM_BARS; bar++) {
+ bar = pci_epc_get_next_free_bar(epc_features, bar);
+ if (bar == NO_BAR)
+ return NO_BAR;
+ if (bar != exclude &&
+ !pci_epf_dma_bar_has_fixed_resource(epf_dma, bar))
+ return bar;
+ }
+
+ return NO_BAR;
+}
+
+static size_t pci_epf_dma_align_size(size_t size, size_t align)
+{
+ if (!align)
+ return size;
+
+ return ALIGN(size, align);
+}
+
+static int pci_epf_dma_reuse_submap(struct pci_epf_dma *epf_dma,
+ unsigned int map_count,
+ dma_addr_t phys_addr, size_t map_size,
+ size_t offset, size_t *next_offset_in_bar,
+ u64 *res_offset_in_bar)
+{
+ struct pci_epf_dma_bar_map *map;
+ u64 delta;
+ size_t merged_size, next;
+ u64 res_map_end, submap_bar_end, submap_phys_end;
+ unsigned int i;
+
+ if (check_add_overflow(phys_addr, map_size, &res_map_end))
+ return -EOVERFLOW;
+
+ for (i = 0; i < map_count; i++) {
+ map = &epf_dma->bar_maps[i];
+ if (!map->needs_submap || map->bar != epf_dma->dma_window_bar)
+ continue;
+
+ if (check_add_overflow(map->phys_addr, map->map_size,
+ &submap_phys_end) ||
+ check_add_overflow(map->submap_offset_in_bar,
+ map->map_size, &submap_bar_end))
+ return -EOVERFLOW;
+
+ /*
+ * Reuse a submap that already covers this aligned resource
+ * window.
+ */
+ if (phys_addr >= map->phys_addr &&
+ res_map_end <= submap_phys_end) {
+ if (check_add_overflow(phys_addr - map->phys_addr,
+ offset, &delta) ||
+ check_add_overflow(map->submap_offset_in_bar,
+ delta, res_offset_in_bar))
+ return -EOVERFLOW;
+ return 1;
+ }
+
+ /*
+ * Extend only the BAR-tail submap when the physical ranges are
+ * contiguous.
+ */
+ if (submap_phys_end == phys_addr &&
+ submap_bar_end == *next_offset_in_bar) {
+ if (check_add_overflow(map->map_size, map_size,
+ &merged_size) ||
+ check_add_overflow(*next_offset_in_bar, map_size,
+ &next) ||
+ check_add_overflow(*next_offset_in_bar, offset,
+ res_offset_in_bar))
+ return -EOVERFLOW;
+
+ map->map_size = merged_size;
+ *next_offset_in_bar = next;
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
+static int pci_epf_dma_add_map(struct pci_epf_dma *epf_dma,
+ const struct pci_epc_aux_resource *res,
+ size_t align, size_t *next_offset_in_bar,
+ unsigned int *map_idx)
+{
+ dma_addr_t phys_addr;
+ size_t map_size, offset = 0, next;
+ u64 res_offset_in_bar;
+ unsigned int i;
+ int ret;
+
+ if (!res || !res->size)
+ return -EINVAL;
+
+ for (i = 0; i < *map_idx; i++) {
+ if (epf_dma->bar_maps[i].res == res)
+ return 0;
+ }
+
+ if (res->bar != NO_BAR) {
+ if (res->bar < BAR_0 || res->bar >= PCI_STD_NUM_BARS)
+ return -EINVAL;
+ if (res->bar == epf_dma->metadata_bar ||
+ res->bar == epf_dma->dma_window_bar)
+ return -EINVAL;
+
+ epf_dma->bar_maps[*map_idx] = (struct pci_epf_dma_bar_map) {
+ .res = res,
+ .bar = res->bar,
+ .res_offset_in_bar = res->bar_offset,
+ .map_size = res->size,
+ };
+ (*map_idx)++;
+
+ return 0;
+ }
+
+ if (epf_dma->dma_window_bar == NO_BAR)
+ return -EOPNOTSUPP;
+
+ phys_addr = res->phys_addr;
+ /* Map the aligned window that contains this resource. */
+ if (align) {
+ phys_addr = ALIGN_DOWN(res->phys_addr, align);
+ offset = res->phys_addr - phys_addr;
+ }
+
+ if (check_add_overflow(res->size, offset, &map_size))
+ return -EOVERFLOW;
+ map_size = pci_epf_dma_align_size(map_size, align);
+
+ ret = pci_epf_dma_reuse_submap(epf_dma, *map_idx, phys_addr, map_size,
+ offset, next_offset_in_bar,
+ &res_offset_in_bar);
+ if (ret < 0)
+ return ret;
+ if (ret) {
+ epf_dma->bar_maps[*map_idx] = (struct pci_epf_dma_bar_map) {
+ .res = res,
+ .bar = epf_dma->dma_window_bar,
+ .res_offset_in_bar = res_offset_in_bar,
+ .phys_addr = res->phys_addr,
+ .map_size = res->size,
+ };
+
+ (*map_idx)++;
+
+ return 0;
+ }
+
+ if (check_add_overflow(*next_offset_in_bar, map_size, &next))
+ return -EOVERFLOW;
+ if (check_add_overflow(*next_offset_in_bar, offset, &res_offset_in_bar))
+ return -EOVERFLOW;
+
+ epf_dma->bar_maps[*map_idx] = (struct pci_epf_dma_bar_map) {
+ .res = res,
+ .bar = epf_dma->dma_window_bar,
+ .res_offset_in_bar = res_offset_in_bar,
+ .submap_offset_in_bar = *next_offset_in_bar,
+ .phys_addr = phys_addr,
+ .map_size = map_size,
+ .needs_submap = true,
+ };
+
+ *next_offset_in_bar = next;
+ (*map_idx)++;
+
+ return 0;
+}
+
+static void pci_epf_dma_unmap_submaps(struct pci_epf_dma *epf_dma)
+{
+ struct pci_epc *epc = epf_dma->epf->epc;
+ struct device *dev;
+ unsigned int i;
+
+ if (!epc)
+ return;
+
+ dev = epc->dev.parent;
+
+ for (i = 0; i < epf_dma->num_bar_maps; i++) {
+ struct pci_epf_dma_bar_map *map = &epf_dma->bar_maps[i];
+
+ if (!map->dma_mapped)
+ continue;
+
+ dma_unmap_resource(dev, map->dma_addr, map->map_size,
+ DMA_BIDIRECTIONAL, 0);
+ map->dma_mapped = false;
+ }
+}
+
+static int pci_epf_dma_map_submaps(struct pci_epf_dma *epf_dma)
+{
+ struct pci_epc *epc = epf_dma->epf->epc;
+ struct device *dev = epc->dev.parent;
+ unsigned int i;
+
+ for (i = 0; i < epf_dma->num_bar_maps; i++) {
+ struct pci_epf_dma_bar_map *map = &epf_dma->bar_maps[i];
+
+ if (!map->needs_submap)
+ continue;
+
+ /*
+ * Descriptor resources carry endpoint-local DMA addresses.
+ * Controller MMIO resources are CPU physical addresses, so map
+ * them for the EPC parent before programming inbound windows.
+ */
+ if (map->res->type != PCI_EPC_AUX_DMA_CTRL_MMIO)
+ continue;
+
+ map->dma_addr = dma_map_resource(dev, map->phys_addr,
+ map->map_size,
+ DMA_BIDIRECTIONAL, 0);
+ if (dma_mapping_error(dev, map->dma_addr)) {
+ pci_epf_dma_unmap_submaps(epf_dma);
+ return -EIO;
+ }
+
+ map->dma_mapped = true;
+ }
+
+ return 0;
+}
+
+static dma_addr_t pci_epf_dma_submap_addr(const struct pci_epf_dma_bar_map *map)
+{
+ if (map->dma_mapped)
+ return map->dma_addr;
+
+ return map->phys_addr;
+}
+
+static const struct pci_epf_dma_bar_map *
+pci_epf_dma_find_map(struct pci_epf_dma *epf_dma,
+ const struct pci_epc_aux_resource *res)
+{
+ unsigned int i;
+
+ for (i = 0; i < epf_dma->num_bar_maps; i++) {
+ if (epf_dma->bar_maps[i].res == res)
+ return &epf_dma->bar_maps[i];
+ }
+
+ return NULL;
+}
+
+static bool pci_epf_dma_needs_dma_window(struct pci_epf_dma *epf_dma)
+{
+ unsigned int i;
+
+ if (epf_dma->ctrl && epf_dma->ctrl->bar == NO_BAR)
+ return true;
+
+ for (i = 0; i < epf_dma->wr_chans; i++) {
+ if (epf_dma->ep_to_rc_desc[i] &&
+ epf_dma->ep_to_rc_desc[i]->bar == NO_BAR)
+ return true;
+ }
+
+ for (i = 0; i < epf_dma->rd_chans; i++) {
+ if (epf_dma->rc_to_ep_desc[i] &&
+ epf_dma->rc_to_ep_desc[i]->bar == NO_BAR)
+ return true;
+ }
+
+ return false;
+}
+
+static const struct pci_epc_aux_resource *
+pci_epf_dma_find_desc_mem(const struct pci_epc_aux_resource *res, int count,
+ u16 id)
+{
+ int i;
+
+ for (i = 0; i < count; i++) {
+ if (res[i].type == PCI_EPC_AUX_DMA_DESC_MEM &&
+ res[i].u.dma_desc.id == id)
+ return &res[i];
+ }
+
+ return NULL;
+}
+
+static int pci_epf_dma_collect_resources(struct pci_epf_dma *epf_dma)
+{
+ const struct pci_epc_aux_resource *ep_to_rc_aux_chan[EDMA_MAX_WR_CH] = {};
+ const struct pci_epc_aux_resource *rc_to_ep_aux_chan[EDMA_MAX_RD_CH] = {};
+ const struct pci_epc_aux_resource *ep_to_rc_desc[EDMA_MAX_WR_CH] = {};
+ const struct pci_epc_aux_resource *rc_to_ep_desc[EDMA_MAX_RD_CH] = {};
+ const struct pci_epc_aux_resource *ctrl = NULL;
+ struct pci_epf *epf = epf_dma->epf;
+ struct pci_epc *epc = epf->epc;
+ struct device *dev = &epf->dev;
+ int count, i, ret;
+
+ count = pci_epc_get_aux_resources_count(epc, epf->func_no,
+ epf->vfunc_no);
+ if (count <= 0)
+ return count ?: -ENODEV;
+
+ struct pci_epc_aux_resource *res __free(kfree) =
+ kzalloc_objs(*res, count);
+ if (!res)
+ return -ENOMEM;
+
+ ret = pci_epc_get_aux_resources(epc, epf->func_no, epf->vfunc_no,
+ res, count);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < count; i++) {
+ switch (res[i].type) {
+ case PCI_EPC_AUX_DMA_CTRL_MMIO:
+ if (ctrl)
+ return -EINVAL;
+ ctrl = &res[i];
+ break;
+ case PCI_EPC_AUX_DMA_CHAN: {
+ u16 hw_ch = res[i].u.dma_chan.hw_ch;
+
+ switch (res[i].u.dma_chan.dir) {
+ case PCI_EPC_AUX_DMA_EP_TO_RC:
+ if (hw_ch >= EDMA_MAX_WR_CH ||
+ ep_to_rc_aux_chan[hw_ch])
+ return -EINVAL;
+ ep_to_rc_aux_chan[hw_ch] = &res[i];
+ break;
+ case PCI_EPC_AUX_DMA_RC_TO_EP:
+ if (hw_ch >= EDMA_MAX_RD_CH ||
+ rc_to_ep_aux_chan[hw_ch])
+ return -EINVAL;
+ rc_to_ep_aux_chan[hw_ch] = &res[i];
+ break;
+ default:
+ return -EINVAL;
+ }
+ break;
+ }
+ case PCI_EPC_AUX_DMA_DESC_MEM:
+ if (pci_epf_dma_find_desc_mem(res, i,
+ res[i].u.dma_desc.id))
+ return -EINVAL;
+ break;
+ default:
+ continue;
+ }
+ }
+
+ if (!ctrl)
+ return -ENODEV;
+
+ if (!epf_dma->wr_chans && !epf_dma->rd_chans) {
+ dev_err(dev, "no DMA channels requested\n");
+ return -EINVAL;
+ }
+
+ if (epf_dma->wr_chans > ctrl->u.dma_ctrl.ep_to_rc_ch_cnt ||
+ epf_dma->rd_chans > ctrl->u.dma_ctrl.rc_to_ep_ch_cnt)
+ return -EINVAL;
+
+ switch (ctrl->u.dma_ctrl.reg_layout) {
+ case PCI_EPC_AUX_DMA_REG_LAYOUT_DW_EDMA:
+ ret = pci_epf_dma_validate_dw_edma_ctrl(epf_dma, ctrl);
+ if (ret)
+ return ret;
+ epf_dma->reg_layout = PCI_EP_DMA_METADATA_REG_LAYOUT_DW_EDMA;
+ epf_dma->reg_layout_data = ctrl->u.dma_ctrl.reg_layout_data;
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ for (i = 0; i < epf_dma->wr_chans; i++) {
+ if (!ep_to_rc_aux_chan[i]) {
+ dev_err(dev, "missing dense write DMA channel %d\n", i);
+ return -EINVAL;
+ }
+ }
+
+ for (i = 0; i < epf_dma->rd_chans; i++) {
+ if (!rc_to_ep_aux_chan[i]) {
+ dev_err(dev, "missing dense read DMA channel %d\n", i);
+ return -EINVAL;
+ }
+ }
+
+ for (i = 0; i < epf_dma->wr_chans; i++) {
+ u16 desc_mem_id = ep_to_rc_aux_chan[i]->u.dma_chan.desc_mem_id;
+
+ ep_to_rc_desc[i] = pci_epf_dma_find_desc_mem(res, count, desc_mem_id);
+ if (!ep_to_rc_desc[i]) {
+ dev_err(dev, "missing write DMA descriptor memory %d\n", i);
+ return -EINVAL;
+ }
+ }
+
+ for (i = 0; i < epf_dma->rd_chans; i++) {
+ u16 desc_mem_id = rc_to_ep_aux_chan[i]->u.dma_chan.desc_mem_id;
+
+ rc_to_ep_desc[i] = pci_epf_dma_find_desc_mem(res, count, desc_mem_id);
+ if (!rc_to_ep_desc[i]) {
+ dev_err(dev, "missing read DMA descriptor memory %d\n", i);
+ return -EINVAL;
+ }
+ }
+
+ for (i = 0; i < epf_dma->wr_chans; i++) {
+ ret = pci_epf_dma_claim_channel(epf_dma, ep_to_rc_aux_chan[i],
+ &epf_dma->ep_to_rc_chan[i]);
+ if (ret)
+ goto err_release_channels;
+ }
+
+ for (i = 0; i < epf_dma->rd_chans; i++) {
+ ret = pci_epf_dma_claim_channel(epf_dma, rc_to_ep_aux_chan[i],
+ &epf_dma->rc_to_ep_chan[i]);
+ if (ret)
+ goto err_release_channels;
+ }
+
+ epf_dma->resources = no_free_ptr(res);
+ epf_dma->num_resources = count;
+ epf_dma->ctrl = ctrl;
+ memcpy(epf_dma->ep_to_rc_aux_chan, ep_to_rc_aux_chan,
+ sizeof(ep_to_rc_aux_chan));
+ memcpy(epf_dma->rc_to_ep_aux_chan, rc_to_ep_aux_chan,
+ sizeof(rc_to_ep_aux_chan));
+ memcpy(epf_dma->ep_to_rc_desc, ep_to_rc_desc, sizeof(ep_to_rc_desc));
+ memcpy(epf_dma->rc_to_ep_desc, rc_to_ep_desc, sizeof(rc_to_ep_desc));
+
+ return 0;
+
+err_release_channels:
+ pci_epf_dma_release_channels(epf_dma);
+
+ return ret;
+}
+
+static void pci_epf_dma_metadata_write(__le32 *metadata, u16 metadata_off,
+ u32 val)
+{
+ metadata[metadata_off / sizeof(*metadata)] = cpu_to_le32(val);
+}
+
+static void pci_epf_dma_metadata_write64(__le32 *metadata, u16 metadata_off,
+ u64 val)
+{
+ pci_epf_dma_metadata_write(metadata, metadata_off, lower_32_bits(val));
+ pci_epf_dma_metadata_write(metadata, metadata_off + sizeof(u32),
+ upper_32_bits(val));
+}
+
+static int pci_epf_dma_build_ch_entry(const struct pci_epc_aux_resource *chan,
+ const struct pci_epf_dma_bar_map *map,
+ __le32 *metadata, u16 entry)
+{
+ const struct pci_epc_aux_resource *res = map->res;
+ u32 ctrl;
+
+ if (res->size > U32_MAX)
+ return -EOVERFLOW;
+
+ ctrl = FIELD_PREP(PCI_EP_DMA_METADATA_CH_CTRL_HW_CH,
+ chan->u.dma_chan.hw_ch) |
+ FIELD_PREP(PCI_EP_DMA_METADATA_CH_CTRL_DESC_BAR, map->bar);
+
+ pci_epf_dma_metadata_write(metadata, entry + PCI_EP_DMA_METADATA_CH_CTRL,
+ ctrl);
+ pci_epf_dma_metadata_write64(metadata,
+ entry + PCI_EP_DMA_METADATA_CH_DESC_OFF_LO,
+ map->res_offset_in_bar);
+ pci_epf_dma_metadata_write(metadata,
+ entry + PCI_EP_DMA_METADATA_CH_DESC_SIZE,
+ (u32)res->size);
+ pci_epf_dma_metadata_write64(metadata,
+ entry + PCI_EP_DMA_METADATA_CH_DESC_ADDR_LO,
+ res->phys_addr);
+
+ return 0;
+}
+
+static void pci_epf_dma_set_metadata_ready(struct pci_epf_dma *epf_dma,
+ bool ready)
+{
+ __le32 *metadata = epf_dma->metadata_addr;
+ __le32 *ctrl_ptr;
+ u32 ctrl;
+
+ if (!metadata)
+ return;
+
+ ctrl_ptr = &metadata[PCI_EP_DMA_METADATA_CTRL / sizeof(*metadata)];
+ ctrl = le32_to_cpu(READ_ONCE(*ctrl_ptr));
+ if (ready)
+ ctrl |= PCI_EP_DMA_METADATA_CTRL_READY;
+ else
+ ctrl &= ~PCI_EP_DMA_METADATA_CTRL_READY;
+ if (ready)
+ dma_wmb();
+ WRITE_ONCE(*ctrl_ptr, cpu_to_le32(ctrl));
+ if (ready)
+ epf_dma->channels_exposed = true;
+}
+
+static bool pci_epf_dma_metadata_host_requested(struct pci_epf_dma *epf_dma)
+{
+ __le32 *metadata = epf_dma->metadata_addr;
+ u32 host_ctrl;
+
+ if (!metadata)
+ return false;
+
+ host_ctrl = le32_to_cpu(READ_ONCE(metadata[PCI_EP_DMA_METADATA_HOST_CTRL /
+ sizeof(*metadata)]));
+
+ return host_ctrl & PCI_EP_DMA_METADATA_HOST_CTRL_REQ;
+}
+
+static void pci_epf_dma_clear_metadata_status(struct pci_epf_dma *epf_dma)
+{
+ __le32 *metadata = epf_dma->metadata_addr;
+ __le32 *ctrl_ptr;
+ u32 ctrl;
+
+ if (!metadata)
+ return;
+
+ WRITE_ONCE(metadata[PCI_EP_DMA_METADATA_HOST_CTRL / sizeof(*metadata)], 0);
+
+ ctrl_ptr = &metadata[PCI_EP_DMA_METADATA_CTRL / sizeof(*metadata)];
+ ctrl = le32_to_cpu(READ_ONCE(*ctrl_ptr));
+ ctrl &= ~PCI_EP_DMA_METADATA_CTRL_READY;
+ WRITE_ONCE(*ctrl_ptr, cpu_to_le32(ctrl));
+}
+
+static int pci_epf_dma_build_metadata(struct pci_epf_dma *epf_dma)
+{
+ const struct pci_epf_dma_bar_map *ctrl_map;
+ u16 entry_size = PCI_EP_DMA_METADATA_CH_ENTRY_SIZE;
+ u16 wr_table, rd_table, total_len;
+ __le32 *metadata = epf_dma->metadata_addr;
+ unsigned int i;
+ int ret;
+
+ if (!metadata)
+ return -EINVAL;
+
+ ctrl_map = pci_epf_dma_find_map(epf_dma, epf_dma->ctrl);
+ if (!ctrl_map)
+ return -EINVAL;
+ if (epf_dma->wr_chans > FIELD_MAX(PCI_EP_DMA_METADATA_CTRL_WR_CH_COUNT) ||
+ epf_dma->rd_chans > FIELD_MAX(PCI_EP_DMA_METADATA_CTRL_RD_CH_COUNT) ||
+ entry_size > FIELD_MAX(PCI_EP_DMA_METADATA_CTRL_CH_ENTRY_SIZE) ||
+ ctrl_map->res->size > U32_MAX)
+ return -EOVERFLOW;
+
+ wr_table = epf_dma->wr_chans ? PCI_EP_DMA_METADATA_HDR_LEN : 0;
+ rd_table = epf_dma->rd_chans ?
+ PCI_EP_DMA_METADATA_HDR_LEN + epf_dma->wr_chans * entry_size : 0;
+ total_len = PCI_EP_DMA_METADATA_HDR_LEN +
+ (epf_dma->wr_chans + epf_dma->rd_chans) * entry_size;
+
+ memset(metadata, 0, total_len);
+
+ pci_epf_dma_metadata_write(metadata, 0, PCI_EP_DMA_METADATA_MAGIC);
+ pci_epf_dma_metadata_write(metadata, PCI_EP_DMA_METADATA_HDR,
+ FIELD_PREP(PCI_EP_DMA_METADATA_HDR_REV,
+ PCI_EP_DMA_METADATA_REV) |
+ FIELD_PREP(PCI_EP_DMA_METADATA_HDR_LEN_FIELD,
+ total_len));
+ pci_epf_dma_metadata_write(metadata, PCI_EP_DMA_METADATA_CTRL,
+ FIELD_PREP(PCI_EP_DMA_METADATA_CTRL_REG_BAR,
+ ctrl_map->bar) |
+ FIELD_PREP(PCI_EP_DMA_METADATA_CTRL_WR_CH_COUNT,
+ epf_dma->wr_chans) |
+ FIELD_PREP(PCI_EP_DMA_METADATA_CTRL_RD_CH_COUNT,
+ epf_dma->rd_chans) |
+ FIELD_PREP(PCI_EP_DMA_METADATA_CTRL_CH_ENTRY_SIZE,
+ entry_size));
+ pci_epf_dma_metadata_write64(metadata,
+ PCI_EP_DMA_METADATA_REG_OFF_LO,
+ ctrl_map->res_offset_in_bar);
+ pci_epf_dma_metadata_write(metadata, PCI_EP_DMA_METADATA_REG_LAYOUT,
+ FIELD_PREP(PCI_EP_DMA_METADATA_REG_LAYOUT_ID,
+ epf_dma->reg_layout) |
+ FIELD_PREP(PCI_EP_DMA_METADATA_REG_LAYOUT_DATA,
+ epf_dma->reg_layout_data));
+ pci_epf_dma_metadata_write(metadata, PCI_EP_DMA_METADATA_REG_SIZE,
+ (u32)ctrl_map->res->size);
+
+ for (i = 0; i < epf_dma->wr_chans; i++) {
+ const struct pci_epf_dma_bar_map *map;
+
+ map = pci_epf_dma_find_map(epf_dma,
+ epf_dma->ep_to_rc_desc[i]);
+ if (!map)
+ return -EINVAL;
+ ret = pci_epf_dma_build_ch_entry(epf_dma->ep_to_rc_aux_chan[i],
+ map, metadata,
+ wr_table + i * entry_size);
+ if (ret)
+ return ret;
+ }
+
+ for (i = 0; i < epf_dma->rd_chans; i++) {
+ const struct pci_epf_dma_bar_map *map;
+
+ map = pci_epf_dma_find_map(epf_dma,
+ epf_dma->rc_to_ep_desc[i]);
+ if (!map)
+ return -EINVAL;
+ ret = pci_epf_dma_build_ch_entry(epf_dma->rc_to_ep_aux_chan[i],
+ map, metadata,
+ rd_table + i * entry_size);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int pci_epf_dma_reserve_msix(struct pci_epf_dma *epf_dma,
+ const struct pci_epc_features *epc_features,
+ size_t *backing_size)
+{
+ struct pci_epf *epf = epf_dma->epf;
+ size_t msix_table_size, pba_size, next;
+ unsigned int nvec = epf->msix_interrupts;
+
+ epf_dma->msix_table_offset = 0;
+
+ if (!epc_features->msix_capable || !nvec)
+ return 0;
+
+ next = ALIGN(*backing_size, 8);
+ if (next > U32_MAX)
+ return -EOVERFLOW;
+ epf_dma->msix_table_offset = next;
+
+ if (check_mul_overflow(PCI_MSIX_ENTRY_SIZE, nvec, &msix_table_size))
+ return -EOVERFLOW;
+
+ pba_size = ALIGN(DIV_ROUND_UP(nvec, 8), 8);
+ if (check_add_overflow(next, msix_table_size, &next) ||
+ next > U32_MAX ||
+ check_add_overflow(next, pba_size, &next))
+ return -EOVERFLOW;
+
+ *backing_size = next;
+
+ return 0;
+}
+
+static int pci_epf_dma_build_layout(struct pci_epf_dma *epf_dma,
+ const struct pci_epc_features *epc_features)
+{
+ struct pci_epf *epf = epf_dma->epf;
+ struct device *dev = &epf->dev;
+ struct pci_epf_bar *bar;
+ unsigned int max_maps, map_idx = 0, sub_idx = 0;
+ size_t align = epc_features->align;
+ size_t metadata_size, metadata_backing_size, metadata_bar_size;
+ size_t mapped_size = 0, dma_window_bar_size;
+ int i, ret;
+
+ metadata_size = PCI_EP_DMA_METADATA_HDR_LEN;
+ metadata_size += (epf_dma->wr_chans + epf_dma->rd_chans) *
+ PCI_EP_DMA_METADATA_CH_ENTRY_SIZE;
+ metadata_backing_size = metadata_size;
+ ret = pci_epf_dma_reserve_msix(epf_dma, epc_features,
+ &metadata_backing_size);
+ if (ret)
+ return ret;
+ metadata_bar_size = pci_epf_dma_align_size(metadata_backing_size,
+ align);
+
+ epf_dma->metadata_addr = pci_epf_alloc_space(epf, metadata_bar_size,
+ epf_dma->metadata_bar,
+ epc_features,
+ PRIMARY_INTERFACE);
+ if (!epf_dma->metadata_addr) {
+ dev_err(dev, "failed to allocate BAR%d metadata space\n",
+ epf_dma->metadata_bar);
+ return -ENOMEM;
+ }
+ memset(epf_dma->metadata_addr, 0, epf->bar[epf_dma->metadata_bar].size);
+
+ /* One map for DMA controller registers, plus one per channel. */
+ max_maps = 1 + epf_dma->wr_chans + epf_dma->rd_chans;
+ epf_dma->bar_maps = kzalloc_objs(*epf_dma->bar_maps, max_maps);
+ if (!epf_dma->bar_maps)
+ return -ENOMEM;
+
+ ret = pci_epf_dma_add_map(epf_dma, epf_dma->ctrl, align,
+ &mapped_size, &map_idx);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < epf_dma->wr_chans; i++) {
+ ret = pci_epf_dma_add_map(epf_dma,
+ epf_dma->ep_to_rc_desc[i], align,
+ &mapped_size, &map_idx);
+ if (ret)
+ return ret;
+ }
+
+ for (i = 0; i < epf_dma->rd_chans; i++) {
+ ret = pci_epf_dma_add_map(epf_dma,
+ epf_dma->rc_to_ep_desc[i], align,
+ &mapped_size, &map_idx);
+ if (ret)
+ return ret;
+ }
+
+ epf_dma->num_bar_maps = map_idx;
+
+ ret = pci_epf_dma_build_metadata(epf_dma);
+ if (ret)
+ return ret;
+
+ /* Some DMA resources may already be visible through another map. */
+ for (i = 0; i < epf_dma->num_bar_maps; i++) {
+ if (epf_dma->bar_maps[i].needs_submap)
+ epf_dma->num_submaps++;
+ }
+ if (!epf_dma->num_submaps)
+ return 0;
+
+ ret = pci_epf_dma_map_submaps(epf_dma);
+ if (ret)
+ return ret;
+
+ dma_window_bar_size = mapped_size;
+ epf_dma->dma_window_addr =
+ pci_epf_alloc_space(epf, dma_window_bar_size,
+ epf_dma->dma_window_bar, epc_features,
+ PRIMARY_INTERFACE);
+ if (!epf_dma->dma_window_addr) {
+ dev_err(dev, "failed to allocate BAR%d DMA window space\n",
+ epf_dma->dma_window_bar);
+ return -ENOMEM;
+ }
+ bar = &epf->bar[epf_dma->dma_window_bar];
+ memset(epf_dma->dma_window_addr, 0, bar->size);
+
+ if (bar->size > mapped_size)
+ epf_dma->num_submaps++;
+
+ epf_dma->submaps = kzalloc_objs(*epf_dma->submaps, epf_dma->num_submaps);
+ if (!epf_dma->submaps)
+ return -ENOMEM;
+
+ for (i = 0; i < epf_dma->num_bar_maps; i++) {
+ struct pci_epf_dma_bar_map *map = &epf_dma->bar_maps[i];
+
+ if (!map->needs_submap)
+ continue;
+
+ epf_dma->submaps[sub_idx++] = (struct pci_epf_bar_submap) {
+ .phys_addr = pci_epf_dma_submap_addr(map),
+ .size = map->map_size,
+ };
+ }
+
+ /* Cover any BAR tail padding with the allocated scratch space. */
+ if (bar->size > mapped_size) {
+ epf_dma->submaps[sub_idx++] = (struct pci_epf_bar_submap) {
+ .phys_addr = bar->phys_addr + mapped_size,
+ .size = bar->size - mapped_size,
+ };
+ }
+
+ return 0;
+}
+
+static void pci_epf_dma_free_layout(struct pci_epf_dma *epf_dma)
+{
+ struct pci_epf *epf = epf_dma->epf;
+ struct pci_epf_bar *bar;
+
+ pci_epf_dma_release_channels(epf_dma);
+
+ if (epf_dma->dma_window_addr) {
+ bar = &epf->bar[epf_dma->dma_window_bar];
+ bar->submap = NULL;
+ bar->num_submap = 0;
+ }
+ epf_dma->submaps_programmed = false;
+
+ kfree(epf_dma->submaps);
+ epf_dma->submaps = NULL;
+ epf_dma->num_submaps = 0;
+
+ pci_epf_dma_unmap_submaps(epf_dma);
+
+ kfree(epf_dma->bar_maps);
+ epf_dma->bar_maps = NULL;
+ epf_dma->num_bar_maps = 0;
+
+ kfree(epf_dma->resources);
+ epf_dma->resources = NULL;
+ epf_dma->num_resources = 0;
+ epf_dma->ctrl = NULL;
+ memset(epf_dma->ep_to_rc_aux_chan, 0, sizeof(epf_dma->ep_to_rc_aux_chan));
+ memset(epf_dma->rc_to_ep_aux_chan, 0, sizeof(epf_dma->rc_to_ep_aux_chan));
+ memset(epf_dma->ep_to_rc_desc, 0, sizeof(epf_dma->ep_to_rc_desc));
+ memset(epf_dma->rc_to_ep_desc, 0, sizeof(epf_dma->rc_to_ep_desc));
+
+ if (epf_dma->dma_window_addr) {
+ pci_epf_free_space(epf, epf_dma->dma_window_addr,
+ epf_dma->dma_window_bar,
+ PRIMARY_INTERFACE);
+ epf_dma->dma_window_addr = NULL;
+ }
+
+ if (epf_dma->metadata_addr) {
+ pci_epf_free_space(epf, epf_dma->metadata_addr,
+ epf_dma->metadata_bar,
+ PRIMARY_INTERFACE);
+ epf_dma->metadata_addr = NULL;
+ }
+ epf_dma->msix_table_offset = 0;
+
+ if (epf_dma->metadata_bar_auto)
+ epf_dma->metadata_bar = NO_BAR;
+ if (epf_dma->dma_window_bar_auto)
+ epf_dma->dma_window_bar = NO_BAR;
+ epf_dma->metadata_bar_auto = false;
+ epf_dma->dma_window_bar_auto = false;
+}
+
+static int pci_epf_dma_program_submaps(struct pci_epf_dma *epf_dma)
+{
+ struct pci_epf *epf = epf_dma->epf;
+ struct pci_epf_bar *bar;
+ int ret;
+
+ if (!epf_dma->dma_window_addr) {
+ pci_epf_dma_set_metadata_ready(epf_dma, true);
+ return 0;
+ }
+
+ if (epf_dma->submaps_programmed)
+ return 0;
+
+ bar = &epf->bar[epf_dma->dma_window_bar];
+ bar->submap = epf_dma->submaps;
+ bar->num_submap = epf_dma->num_submaps;
+
+ ret = pci_epc_set_bar(epf->epc, epf->func_no, epf->vfunc_no, bar);
+ if (ret) {
+ bar->submap = NULL;
+ bar->num_submap = 0;
+ return ret;
+ }
+
+ epf_dma->submaps_programmed = true;
+ pci_epf_dma_set_metadata_ready(epf_dma, true);
+
+ return 0;
+}
+
+static void pci_epf_dma_map_work(struct work_struct *work)
+{
+ struct pci_epf_dma *epf_dma =
+ container_of(to_delayed_work(work), struct pci_epf_dma,
+ map_work);
+ struct pci_epf *epf = epf_dma->epf;
+ int ret;
+
+ if (!epf->epc)
+ return;
+
+ if (!epf->epc->init_complete) {
+ schedule_delayed_work(&epf_dma->map_work,
+ msecs_to_jiffies(PCI_EPF_DMA_HOST_REQ_POLL_MS));
+ return;
+ }
+
+ if (!pci_epf_dma_metadata_host_requested(epf_dma)) {
+ schedule_delayed_work(&epf_dma->map_work,
+ msecs_to_jiffies(PCI_EPF_DMA_HOST_REQ_POLL_MS));
+ return;
+ }
+
+ ret = pci_epf_dma_program_submaps(epf_dma);
+ if (ret) {
+ /*
+ * Do not retry a failed submap update. It usually means the BAR
+ * assignment or EPC/iATU state is unusable for this host request.
+ */
+ dev_err(&epf->dev, "failed to program DMA window BAR submaps: %d\n",
+ ret);
+ }
+}
+
+static int pci_epf_dma_epc_init(struct pci_epf *epf)
+{
+ struct pci_epf_dma *epf_dma = epf_get_drvdata(epf);
+ const struct pci_epc_features *epc_features;
+ struct pci_epc *epc = epf->epc;
+ struct device *dev = &epf->dev;
+ int ret;
+
+ epc_features = pci_epc_get_features(epc, epf->func_no, epf->vfunc_no);
+ if (!epc_features)
+ return -EOPNOTSUPP;
+
+ pci_epf_dma_clear_metadata_status(epf_dma);
+
+ ret = pci_epc_write_header(epc, epf->func_no, epf->vfunc_no,
+ epf->header);
+ if (ret) {
+ dev_err(dev, "configuration header write failed\n");
+ return ret;
+ }
+
+ ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no,
+ &epf->bar[epf_dma->metadata_bar]);
+ if (ret) {
+ dev_err(dev, "BAR%d setup failed: %d\n",
+ epf_dma->metadata_bar, ret);
+ return ret;
+ }
+
+ if (epf_dma->dma_window_addr) {
+ ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no,
+ &epf->bar[epf_dma->dma_window_bar]);
+ if (ret) {
+ dev_err(dev, "BAR%d setup failed: %d\n",
+ epf_dma->dma_window_bar, ret);
+ goto err_clear_metadata_bar;
+ }
+ }
+
+ if (epc_features->msi_capable && epf->msi_interrupts) {
+ ret = pci_epc_set_msi(epc, epf->func_no, epf->vfunc_no,
+ epf->msi_interrupts);
+ if (ret) {
+ dev_err(dev, "MSI setup failed: %d\n", ret);
+ goto err_clear_dma_window_bar;
+ }
+ }
+
+ if (epc_features->msix_capable && epf->msix_interrupts) {
+ ret = pci_epc_set_msix(epc, epf->func_no, epf->vfunc_no,
+ epf->msix_interrupts,
+ epf_dma->metadata_bar,
+ epf_dma->msix_table_offset);
+ if (ret) {
+ dev_err(dev, "MSI-X setup failed: %d\n", ret);
+ goto err_clear_dma_window_bar;
+ }
+ }
+
+ schedule_delayed_work(&epf_dma->map_work, 0);
+
+ return 0;
+
+err_clear_dma_window_bar:
+ if (epf_dma->dma_window_addr)
+ pci_epc_clear_bar(epc, epf->func_no, epf->vfunc_no,
+ &epf->bar[epf_dma->dma_window_bar]);
+err_clear_metadata_bar:
+ pci_epc_clear_bar(epc, epf->func_no, epf->vfunc_no,
+ &epf->bar[epf_dma->metadata_bar]);
+ pci_epf_dma_clear_metadata_status(epf_dma);
+
+ return ret;
+}
+
+static void pci_epf_dma_epc_deinit(struct pci_epf *epf)
+{
+ struct pci_epf_dma *epf_dma = epf_get_drvdata(epf);
+ struct pci_epf_bar *bar;
+
+ cancel_delayed_work_sync(&epf_dma->map_work);
+
+ if (!epf_dma->metadata_addr)
+ return;
+
+ pci_epf_dma_clear_metadata_status(epf_dma);
+ if (epf_dma->dma_window_addr) {
+ bar = &epf->bar[epf_dma->dma_window_bar];
+ pci_epc_clear_bar(epf->epc, epf->func_no, epf->vfunc_no, bar);
+ bar->submap = NULL;
+ bar->num_submap = 0;
+ }
+ pci_epc_clear_bar(epf->epc, epf->func_no, epf->vfunc_no,
+ &epf->bar[epf_dma->metadata_bar]);
+ epf_dma->submaps_programmed = false;
+}
+
+static int pci_epf_dma_link_up(struct pci_epf *epf)
+{
+ struct pci_epf_dma *epf_dma = epf_get_drvdata(epf);
+
+ schedule_delayed_work(&epf_dma->map_work, 0);
+
+ return 0;
+}
+
+static int pci_epf_dma_link_down(struct pci_epf *epf)
+{
+ struct pci_epf_dma *epf_dma = epf_get_drvdata(epf);
+
+ cancel_delayed_work_sync(&epf_dma->map_work);
+ pci_epf_dma_set_metadata_ready(epf_dma, false);
+ /*
+ * Link down can invalidate non-sticky inbound ATU state without going
+ * through pci_epc_clear_bar(). Keep the BAR/submap description intact,
+ * but force the next link-up path to reprogram the subrange mappings
+ * for any still-pending host request.
+ */
+ epf_dma->submaps_programmed = false;
+
+ return 0;
+}
+
+static const struct pci_epc_event_ops pci_epf_dma_event_ops = {
+ .epc_init = pci_epf_dma_epc_init,
+ .epc_deinit = pci_epf_dma_epc_deinit,
+ .link_up = pci_epf_dma_link_up,
+ .link_down = pci_epf_dma_link_down,
+};
+
+static int pci_epf_dma_bind(struct pci_epf *epf)
+{
+ struct pci_epf_dma *epf_dma = epf_get_drvdata(epf);
+ const struct pci_epc_features *epc_features;
+ struct pci_epc *epc = epf->epc;
+ bool needs_dma_window;
+ int ret;
+
+ if (WARN_ON_ONCE(!epc))
+ return -EINVAL;
+
+ epc_features = pci_epc_get_features(epc, epf->func_no, epf->vfunc_no);
+ if (!epc_features)
+ return -EOPNOTSUPP;
+
+ if (!epc_features->msi_capable && !epc_features->msix_capable)
+ return -EOPNOTSUPP;
+
+ if ((!epc_features->msi_capable || !epf->msi_interrupts) &&
+ (!epc_features->msix_capable || !epf->msix_interrupts))
+ return -EINVAL;
+
+ ret = pci_epf_dma_collect_resources(epf_dma);
+ if (ret)
+ return ret;
+
+ epf_dma->metadata_bar_auto = epf_dma->metadata_bar == NO_BAR;
+ epf_dma->dma_window_bar_auto = false;
+
+ if (epf_dma->metadata_bar_auto)
+ epf_dma->metadata_bar =
+ pci_epf_dma_first_usable_bar(epf_dma, epc_features,
+ NO_BAR);
+
+ if (epf_dma->metadata_bar == NO_BAR ||
+ !pci_epf_dma_bar_usable(epc_features, epf_dma->metadata_bar) ||
+ pci_epf_dma_bar_has_fixed_resource(epf_dma, epf_dma->metadata_bar)) {
+ ret = -EINVAL;
+ goto err_free;
+ }
+
+ needs_dma_window = pci_epf_dma_needs_dma_window(epf_dma);
+ if (needs_dma_window) {
+ if (!epc_features->subrange_mapping ||
+ !epc_features->dynamic_inbound_mapping) {
+ ret = -EOPNOTSUPP;
+ goto err_free;
+ }
+
+ epf_dma->dma_window_bar_auto = epf_dma->dma_window_bar == NO_BAR;
+ if (epf_dma->dma_window_bar_auto)
+ epf_dma->dma_window_bar =
+ pci_epf_dma_first_usable_bar(epf_dma, epc_features,
+ epf_dma->metadata_bar);
+ if (epf_dma->dma_window_bar == NO_BAR) {
+ ret = -EOPNOTSUPP;
+ goto err_free;
+ }
+ }
+
+ if (epf_dma->dma_window_bar != NO_BAR) {
+ if (!pci_epf_dma_bar_usable(epc_features,
+ epf_dma->dma_window_bar)) {
+ ret = -EINVAL;
+ goto err_free;
+ }
+ if (epf_dma->metadata_bar == epf_dma->dma_window_bar ||
+ pci_epf_dma_bar_has_fixed_resource(epf_dma,
+ epf_dma->dma_window_bar)) {
+ ret = -EINVAL;
+ goto err_free;
+ }
+ }
+
+ ret = pci_epf_dma_build_layout(epf_dma, epc_features);
+ if (ret)
+ goto err_free;
+
+ return 0;
+
+err_free:
+ pci_epf_dma_free_layout(epf_dma);
+
+ return ret;
+}
+
+static void pci_epf_dma_unbind(struct pci_epf *epf)
+{
+ struct pci_epf_dma *epf_dma = epf_get_drvdata(epf);
+
+ cancel_delayed_work_sync(&epf_dma->map_work);
+ if (epf->epc && epf->epc->init_complete)
+ pci_epf_dma_epc_deinit(epf);
+ pci_epf_dma_free_layout(epf_dma);
+}
+
+#define PCI_EPF_DMA_SHOW(_name, _fmt, _val) \
+static ssize_t pci_epf_dma_##_name##_show(struct config_item *item, \
+ char *page) \
+{ \
+ struct config_group *group = to_config_group(item); \
+ struct pci_epf_dma *epf_dma = to_epf_dma(group); \
+ \
+ return sysfs_emit(page, _fmt "\n", (_val)); \
+}
+
+PCI_EPF_DMA_SHOW(metadata_bar, "%d", (int)epf_dma->metadata_bar)
+PCI_EPF_DMA_SHOW(dma_window_bar, "%d", (int)epf_dma->dma_window_bar)
+
+static ssize_t pci_epf_dma_metadata_bar_store(struct config_item *item, const char *page,
+ size_t len)
+{
+ struct config_group *group = to_config_group(item);
+ struct pci_epf_dma *epf_dma = to_epf_dma(group);
+ int bar, ret;
+
+ if (epf_dma->epf->epc)
+ return -EOPNOTSUPP;
+
+ ret = kstrtoint(page, 0, &bar);
+ if (ret)
+ return ret;
+
+ if (bar != NO_BAR && (bar < BAR_0 || bar >= PCI_STD_NUM_BARS))
+ return -EINVAL;
+ if (bar != NO_BAR && bar == epf_dma->dma_window_bar)
+ return -EINVAL;
+
+ epf_dma->metadata_bar = bar;
+
+ return len;
+}
+
+static ssize_t pci_epf_dma_dma_window_bar_store(struct config_item *item,
+ const char *page, size_t len)
+{
+ struct config_group *group = to_config_group(item);
+ struct pci_epf_dma *epf_dma = to_epf_dma(group);
+ int bar, ret;
+
+ if (epf_dma->epf->epc)
+ return -EOPNOTSUPP;
+
+ ret = kstrtoint(page, 0, &bar);
+ if (ret)
+ return ret;
+
+ if (bar != NO_BAR && (bar < BAR_0 || bar >= PCI_STD_NUM_BARS))
+ return -EINVAL;
+ if (bar != NO_BAR && bar == epf_dma->metadata_bar)
+ return -EINVAL;
+
+ epf_dma->dma_window_bar = bar;
+
+ return len;
+}
+
+PCI_EPF_DMA_SHOW(wr_chans, "%u", (unsigned int)epf_dma->wr_chans)
+
+static ssize_t pci_epf_dma_wr_chans_store(struct config_item *item,
+ const char *page, size_t len)
+{
+ struct config_group *group = to_config_group(item);
+ struct pci_epf_dma *epf_dma = to_epf_dma(group);
+ u16 val;
+ int ret;
+
+ if (epf_dma->epf->epc)
+ return -EOPNOTSUPP;
+
+ ret = kstrtou16(page, 0, &val);
+ if (ret)
+ return ret;
+ if (val > EDMA_MAX_WR_CH)
+ return -EINVAL;
+
+ epf_dma->wr_chans = val;
+
+ return len;
+}
+
+PCI_EPF_DMA_SHOW(rd_chans, "%u", (unsigned int)epf_dma->rd_chans)
+
+static ssize_t pci_epf_dma_rd_chans_store(struct config_item *item,
+ const char *page, size_t len)
+{
+ struct config_group *group = to_config_group(item);
+ struct pci_epf_dma *epf_dma = to_epf_dma(group);
+ u16 val;
+ int ret;
+
+ if (epf_dma->epf->epc)
+ return -EOPNOTSUPP;
+
+ ret = kstrtou16(page, 0, &val);
+ if (ret)
+ return ret;
+ if (val > EDMA_MAX_RD_CH)
+ return -EINVAL;
+
+ epf_dma->rd_chans = val;
+
+ return len;
+}
+
+CONFIGFS_ATTR(pci_epf_dma_, metadata_bar);
+CONFIGFS_ATTR(pci_epf_dma_, dma_window_bar);
+CONFIGFS_ATTR(pci_epf_dma_, wr_chans);
+CONFIGFS_ATTR(pci_epf_dma_, rd_chans);
+
+static struct configfs_attribute *pci_epf_dma_attrs[] = {
+ &pci_epf_dma_attr_metadata_bar,
+ &pci_epf_dma_attr_dma_window_bar,
+ &pci_epf_dma_attr_wr_chans,
+ &pci_epf_dma_attr_rd_chans,
+ NULL,
+};
+
+static const struct config_item_type pci_epf_dma_group_type = {
+ .ct_attrs = pci_epf_dma_attrs,
+ .ct_owner = THIS_MODULE,
+};
+
+static struct config_group *pci_epf_dma_add_cfs(struct pci_epf *epf,
+ struct config_group *group)
+{
+ struct pci_epf_dma *epf_dma = epf_get_drvdata(epf);
+ struct config_group *epf_group = &epf_dma->group;
+ struct device *dev = &epf->dev;
+
+ config_group_init_type_name(epf_group, dev_name(dev),
+ &pci_epf_dma_group_type);
+
+ return epf_group;
+}
+
+static const struct pci_epf_device_id pci_epf_dma_ids[] = {
+ {
+ .name = "pci_epf_dma",
+ },
+ {},
+};
+
+static int pci_epf_dma_probe(struct pci_epf *epf,
+ const struct pci_epf_device_id *id)
+{
+ struct pci_epf_dma *epf_dma;
+
+ epf_dma = devm_kzalloc(&epf->dev, sizeof(*epf_dma), GFP_KERNEL);
+ if (!epf_dma)
+ return -ENOMEM;
+
+ epf->header = &pci_epf_dma_header;
+ epf->event_ops = &pci_epf_dma_event_ops;
+
+ epf_dma->epf = epf;
+ epf_dma->metadata_bar = NO_BAR;
+ epf_dma->dma_window_bar = NO_BAR;
+ INIT_DELAYED_WORK(&epf_dma->map_work, pci_epf_dma_map_work);
+
+ epf_set_drvdata(epf, epf_dma);
+
+ return 0;
+}
+
+static const struct pci_epf_ops pci_epf_dma_ops = {
+ .unbind = pci_epf_dma_unbind,
+ .bind = pci_epf_dma_bind,
+ .add_cfs = pci_epf_dma_add_cfs,
+};
+
+static struct pci_epf_driver pci_epf_dma_driver = {
+ .driver.name = "pci_epf_dma",
+ .probe = pci_epf_dma_probe,
+ .id_table = pci_epf_dma_ids,
+ .ops = &pci_epf_dma_ops,
+ .owner = THIS_MODULE,
+};
+
+static int __init pci_epf_dma_init(void)
+{
+ return pci_epf_register_driver(&pci_epf_dma_driver);
+}
+module_init(pci_epf_dma_init);
+
+static void __exit pci_epf_dma_exit(void)
+{
+ pci_epf_unregister_driver(&pci_epf_dma_driver);
+}
+module_exit(pci_epf_dma_exit);
+
+MODULE_DESCRIPTION("PCI EPF DMA DRIVER");
+MODULE_AUTHOR("Koichiro Den <den@valinux.co.jp>");
+MODULE_LICENSE("GPL");
--
2.51.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v7 09/10] PCI: endpoint: Add DMA endpoint function
2026-08-13 6:37 ` [PATCH v7 09/10] PCI: endpoint: Add DMA endpoint function Koichiro Den
@ 2026-08-13 6:53 ` sashiko-bot
0 siblings, 0 replies; 25+ messages in thread
From: sashiko-bot @ 2026-08-13 6:53 UTC (permalink / raw)
To: Koichiro Den; +Cc: dmaengine, Frank.Li, vkoul, linux-pci
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Critical] Missing `.remove` callback in the EPF driver allows Use-After-Free upon manual driver unbind.
- [High] TOCTOU race in ConfigFS attributes allows bypassing bound state checks, leading to heap buffer overflows.
- [Medium] Mixing goto-based error handling with scope-based `__free()` cleanup in the same function.
--
--- Patch [9]: [PATCH v7 09/10] PCI: endpoint: Add DMA endpoint function ---
commit 59168807cdf2645897d81a698bfcd8a7744d66f2
Author: Koichiro Den <den@valinux.co.jp>
Subject: PCI: endpoint: Add DMA endpoint function
Add pci-epf-dma, an endpoint function that exposes selected
endpoint-integrated DMA channels as a separate PCI DMA controller
function.
> diff --git a/drivers/pci/endpoint/functions/pci-epf-dma.c b/drivers/pci/endpoint/functions/pci-epf-dma.c
> new file mode 100644
> index 0000000000000..7e1c3e184a06b
> --- /dev/null
> +++ b/drivers/pci/endpoint/functions/pci-epf-dma.c
[ ... ]
> +static int pci_epf_dma_collect_resources(struct pci_epf_dma *epf_dma)
> +{
> + const struct pci_epc_aux_resource *ep_to_rc_aux_chan[EDMA_MAX_WR_CH] = {};
> + const struct pci_epc_aux_resource *rc_to_ep_aux_chan[EDMA_MAX_RD_CH] = {};
> + const struct pci_epc_aux_resource *ep_to_rc_desc[EDMA_MAX_WR_CH] = {};
> + const struct pci_epc_aux_resource *rc_to_ep_desc[EDMA_MAX_RD_CH] = {};
> + const struct pci_epc_aux_resource *ctrl = NULL;
> + struct pci_epf *epf = epf_dma->epf;
> + struct pci_epc *epc = epf->epc;
> + struct device *dev = &epf->dev;
> + int count, i, ret;
> +
> + count = pci_epc_get_aux_resources_count(epc, epf->func_no,
> + epf->vfunc_no);
> + if (count <= 0)
> + return count ?: -ENODEV;
> +
> + struct pci_epc_aux_resource *res __free(kfree) =
> + kzalloc_objs(*res, count);
[Severity: Medium]
Does this code mix goto-based error handling and scope-based cleanup in the
same function?
The res variable uses __free(kfree) for cleanup, but later failures jump to
a goto label instead of returning directly:
for (i = 0; i < epf_dma->wr_chans; i++) {
ret = pci_epf_dma_claim_channel(epf_dma, ep_to_rc_aux_chan[i],
&epf_dma->ep_to_rc_chan[i]);
if (ret)
goto err_release_channels;
}
[ ... ]
> +static int pci_epf_dma_build_metadata(struct pci_epf_dma *epf_dma)
> +{
> + const struct pci_epf_dma_bar_map *ctrl_map;
> + u16 entry_size = PCI_EP_DMA_METADATA_CH_ENTRY_SIZE;
> + u16 wr_table, rd_table, total_len;
> + __le32 *metadata = epf_dma->metadata_addr;
> + unsigned int i;
> + int ret;
> +
> + if (!metadata)
> + return -EINVAL;
> +
> + ctrl_map = pci_epf_dma_find_map(epf_dma, epf_dma->ctrl);
> + if (!ctrl_map)
> + return -EINVAL;
> + if (epf_dma->wr_chans > FIELD_MAX(PCI_EP_DMA_METADATA_CTRL_WR_CH_COUNT) ||
> + epf_dma->rd_chans > FIELD_MAX(PCI_EP_DMA_METADATA_CTRL_RD_CH_COUNT) ||
> + entry_size > FIELD_MAX(PCI_EP_DMA_METADATA_CTRL_CH_ENTRY_SIZE) ||
> + ctrl_map->res->size > U32_MAX)
> + return -EOVERFLOW;
> +
> + wr_table = epf_dma->wr_chans ? PCI_EP_DMA_METADATA_HDR_LEN : 0;
> + rd_table = epf_dma->rd_chans ?
> + PCI_EP_DMA_METADATA_HDR_LEN + epf_dma->wr_chans * entry_size : 0;
> + total_len = PCI_EP_DMA_METADATA_HDR_LEN +
> + (epf_dma->wr_chans + epf_dma->rd_chans) * entry_size;
> +
> + memset(metadata, 0, total_len);
[Severity: High]
Can a concurrent write to the configfs attributes cause an out-of-bounds
memset() here?
During the binding process (pci_epf_dma_bind), pci_epf_dma_build_layout()
allocates space based on the current wr_chans. However, the store
function for the attribute checks epf_dma->epf->epc without holding a lock:
static ssize_t pci_epf_dma_wr_chans_store(...)
{
...
if (epf_dma->epf->epc)
return -EOPNOTSUPP;
...
epf_dma->wr_chans = val;
...
}
Could this allow wr_chans to increase after the space is allocated but
before total_len is calculated for this memset?
[ ... ]
> +static struct pci_epf_driver pci_epf_dma_driver = {
> + .driver.name = "pci_epf_dma",
> + .probe = pci_epf_dma_probe,
> + .id_table = pci_epf_dma_ids,
> + .ops = &pci_epf_dma_ops,
> + .owner = THIS_MODULE,
> +};
[Severity: Critical]
If a user manually unbinds the driver via sysfs, does the lack of a .remove
callback lead to a use-after-free?
Because there is no .remove callback, the unbind operation appears to free
the epf_dma structure via devres cleanup, but leaves the epf->event_ops
pointer populated and the map_work delayed work still pending.
Could an in-flight map_work execution or a subsequent EPC link event try to
dereference the freed epf_dma memory?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813063757.3131865-1-den@valinux.co.jp?part=9
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH v7 10/10] Documentation: PCI: Add PCI DMA endpoint function documentation
2026-08-13 6:37 [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Koichiro Den
` (8 preceding siblings ...)
2026-08-13 6:37 ` [PATCH v7 09/10] PCI: endpoint: Add DMA endpoint function Koichiro Den
@ 2026-08-13 6:37 ` Koichiro Den
2026-08-13 6:46 ` sashiko-bot
2026-08-13 11:46 ` [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Niklas Cassel
10 siblings, 1 reply; 25+ messages in thread
From: Koichiro Den @ 2026-08-13 6:37 UTC (permalink / raw)
To: Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Frank Li, Bjorn Helgaas, Jonathan Corbet,
Shuah Khan, Randy Dunlap, Vinod Koul, Jingoo Han,
Lorenzo Pieralisi, Rob Herring, Niklas Cassel, Damien Le Moal,
Arnd Bergmann
Cc: Marek Vasut, Yoshihiro Shimoda, linux-pci, linux-doc,
linux-kernel, dmaengine
Add a function description and a user guide for pci-epf-dma. Describe
the BAR-resident metadata consumed by dw-edma-pcie, the configfs
attributes, endpoint controller requirements and the host-side DMAengine
usage model.
Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
Changes in v7:
- No changes.
Note: This patch was previously posted as part of the separate part 3
series. No v6 of that series was sent.
Documentation/PCI/endpoint/index.rst | 2 +
.../PCI/endpoint/pci-dma-function.rst | 188 ++++++++++++++++
Documentation/PCI/endpoint/pci-dma-howto.rst | 201 ++++++++++++++++++
3 files changed, 391 insertions(+)
create mode 100644 Documentation/PCI/endpoint/pci-dma-function.rst
create mode 100644 Documentation/PCI/endpoint/pci-dma-howto.rst
diff --git a/Documentation/PCI/endpoint/index.rst b/Documentation/PCI/endpoint/index.rst
index dd1f62e731c9..cd4107e02ec2 100644
--- a/Documentation/PCI/endpoint/index.rst
+++ b/Documentation/PCI/endpoint/index.rst
@@ -15,6 +15,8 @@ PCI Endpoint Framework
pci-ntb-howto
pci-vntb-function
pci-vntb-howto
+ pci-dma-function
+ pci-dma-howto
pci-nvme-function
function/binding/pci-test
diff --git a/Documentation/PCI/endpoint/pci-dma-function.rst b/Documentation/PCI/endpoint/pci-dma-function.rst
new file mode 100644
index 000000000000..4de02553f5ff
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-dma-function.rst
@@ -0,0 +1,188 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+================
+PCI DMA Function
+================
+
+:Author: Koichiro Den <den@valinux.co.jp>
+
+The PCI DMA endpoint function exposes an endpoint-integrated DMA controller
+to the PCI host as a PCI DMA controller. A matching host-side driver
+discovers the endpoint DMA metadata and registers the delegated channels with
+the Linux DMAengine framework, so host DMAengine clients can submit
+transfers.
+
+An endpoint Linux system can already use an endpoint-integrated DMA
+controller locally through the normal DMAengine API, for example to transfer
+data between endpoint memory and host addresses reachable over PCI. The PCI
+DMA function provides a different ownership model: it delegates selected
+local DMA channels to the host, so a host DMAengine client can request and
+program those endpoint-side channels through the host's DMAengine API.
+
+To make that possible, the endpoint function publishes the DMA controller
+register window and descriptor memory layout to the host, reserves the
+selected local DMA channels on the endpoint side, and lets the host program
+those channels directly.
+
+Constructs Used for Implementing DMA
+====================================
+
+The PCI DMA function uses the following endpoint-side resources and
+configuration:
+
+ 1) DMA controller register window
+ 2) DMA descriptor memory for endpoint-to-RC channels
+ 3) DMA descriptor memory for RC-to-endpoint channels
+ 4) MSI or MSI-X interrupt vectors selected through configfs
+ 5) One endpoint BAR used to publish metadata
+ 6) If needed, one endpoint BAR used for dynamically mapped DMA windows
+
+The endpoint controller reports the DMA controller register and descriptor
+resources through the endpoint auxiliary resource interface. The PCI DMA
+function uses those descriptions to build the host-visible metadata and to map
+resources that are not already visible to the host.
+
+DMA Controller Register Window
+------------------------------
+
+It contains the DMA controller registers programmed by the host-side driver
+to submit transfers, control channels and handle DMA interrupts.
+
+DMA Descriptor Memory
+---------------------
+
+It contains the descriptor memory used by the DMA controller. The PCI DMA
+function exposes descriptor memory for the delegated endpoint-to-RC and
+RC-to-endpoint channels.
+
+MSI/MSI-X Interrupt Vectors
+---------------------------
+
+They are used by the delegated DMA channels to signal completion and error
+conditions to the host-side driver.
+
+Metadata BAR
+------------
+
+It is the endpoint BAR used to publish the endpoint DMA metadata and handshake
+bits. The BAR remains stable while the endpoint function programs the DMA
+windows.
+
+DMA Window BAR
+--------------
+
+It is the endpoint BAR used for DMA resources that are not already visible
+through a fixed BAR. The endpoint function may switch this BAR to subrange
+mapping after the host-side driver has found the metadata BAR.
+
+BAR Metadata
+============
+
+The endpoint function places a small metadata block at the beginning of the
+selected metadata BAR. The format is defined in
+``include/linux/pci-ep-dma.h``.
+
+The host-side driver scans the function's assigned memory BARs, looks for the
+endpoint DMA metadata magic, requests DMA window programming, waits for the
+READY bit, and then parses the metadata to find the DMA register window and
+descriptor windows.
+
+::
+
+ +----------------------+ metadata BAR offset 0
+ | endpoint DMA metadata|
+ +----------------------+
+ | optional padding |
+ +----------------------+
+
+ +----------------------+ DMA window BAR offset 0
+ | mapped DMA resources |
+ +----------------------+
+ | optional padding |
+ +----------------------+
+
+The metadata can also reference resources that are already host-visible
+through fixed BARs. For example, an endpoint controller may expose the DMA
+controller register window at a fixed BAR offset while descriptor memories
+are mapped into the DMA window BAR by the endpoint function.
+
+The metadata is BAR-resident instead of a self-contained PCI Vendor-Specific
+Extended Capability (VSEC). Some endpoint controllers do not provide writable
+configuration-space backing storage large enough for a new VSEC payload, while
+they can map endpoint memory and controller resources into a BAR.
+
+Channel Ownership
+=================
+
+The ``wr_chans`` attribute exposes endpoint-to-RC DMA write channels. The
+``rd_chans`` attribute exposes RC-to-endpoint DMA read channels. The function
+reserves the selected endpoint-side DMAengine channels so that endpoint-side
+DMAengine clients cannot allocate and use the same hardware channels while
+they are delegated to the host.
+
+The current metadata revision describes channels in dense, zero-based order.
+For example, ``wr_chans = 2`` exposes write channels 0 and 1. Skipping a
+hardware channel in the middle of the exposed range is not supported.
+
+DesignWare eDMA unroll and HDMA compatible layouts require each exposed
+direction to be delegated as a whole. For example, on a controller with two
+write channels, ``wr_chans`` must be either 0 or 2. DesignWare HDMA native
+linked-list mode uses per-channel registers, so a smaller dense prefix can be
+delegated.
+
+Interrupts
+==========
+
+The PCI DMA function exposes DMA interrupts through MSI or MSI-X. The common
+endpoint function ``msi_interrupts`` and ``msix_interrupts`` configfs attributes
+select the interrupt vector counts programmed into endpoint config space. At
+least one MSI or MSI-X vector must be configured before the function is bound
+to an endpoint controller.
+
+Transfer Addressing
+===================
+
+The host-side DMAengine client supplies the endpoint memory address as the
+DMA slave address. For example, the ``dw-edma-pcie`` endpoint DMA metadata
+parser passes that slave address to the DMA controller as a raw endpoint-side
+address instead of translating it through a host PCI BAR resource.
+
+The host memory buffer used as the other side of the transfer is still mapped
+using the normal DMA mapping API on the host.
+
+Endpoint Controller Requirements
+================================
+
+The endpoint controller driver must expose the DMA controller register
+window and per-channel descriptor memories through the endpoint auxiliary
+resource API. Endpoint controllers with other DMA register layouts also need
+matching metadata and host-side DMAengine driver support.
+
+Current DesignWare endpoint DMA support exposes only channels with descriptor
+memory; HDMA native non-linked-list mode is not supported yet.
+
+If any DMA resource is not already host-visible through a fixed BAR, the
+endpoint controller must also support BAR subrange mapping and dynamic inbound
+mapping, because the DMA window BAR is assembled from those resources.
+
+Current Support
+===============
+
+The current host-side support is implemented in ``dw-edma-pcie`` for
+DesignWare eDMA unroll, HDMA compatible and HDMA native linked-list layouts.
+Other PCIe controller DMA implementations need corresponding host-side
+DMAengine driver support.
+
+The ``dw-edma-pcie`` PCI ID table does not contain a generic endpoint DMA PCI
+ID entry. Users need to bind the host-side driver explicitly using
+``driver_override``.
+
+The current metadata revision requires the exposed channels to be a dense
+prefix of the hardware channel numbers.
+
+Security Model
+==============
+
+The interface is intended for trusted endpoint/host deployments. A delegated
+DMA channel can access endpoint memory addresses supplied by a host DMAengine
+client.
diff --git a/Documentation/PCI/endpoint/pci-dma-howto.rst b/Documentation/PCI/endpoint/pci-dma-howto.rst
new file mode 100644
index 000000000000..4bdce63c6f7f
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-dma-howto.rst
@@ -0,0 +1,201 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========================================
+PCI DMA Endpoint Function (EPF) User Guide
+==========================================
+
+:Author: Koichiro Den <den@valinux.co.jp>
+
+This guide shows how to configure the ``pci-epf-dma`` endpoint function driver.
+It uses ``dw-edma-pcie`` as the currently available host-side driver. For the
+hardware model and layout see Documentation/PCI/endpoint/pci-dma-function.rst.
+
+Endpoint Device
+===============
+
+Endpoint Controller Devices
+---------------------------
+
+To find the list of endpoint controller devices in the system::
+
+ # ls /sys/class/pci_epc/
+ e65d0000.pcie-ep
+
+If ``PCI_ENDPOINT_CONFIGFS`` is enabled::
+
+ # ls /sys/kernel/config/pci_ep/controllers
+ e65d0000.pcie-ep
+
+Endpoint Function Drivers
+-------------------------
+
+To find the list of endpoint function drivers in the system::
+
+ # ls /sys/bus/pci-epf/drivers
+ pci_epf_dma pci_epf_test
+
+If ``PCI_ENDPOINT_CONFIGFS`` is enabled::
+
+ # ls /sys/kernel/config/pci_ep/functions
+ pci_epf_dma pci_epf_test
+
+Creating pci-epf-dma Device
+---------------------------
+
+Create a ``pci-epf-dma`` device with configfs::
+
+ # mount -t configfs none /sys/kernel/config
+ # cd /sys/kernel/config/pci_ep/
+ # mkdir functions/pci_epf_dma/dma0
+
+The "mkdir dma0" above creates the ``pci-epf-dma`` function device that will
+be probed by the ``pci_epf_dma`` driver.
+
+The PCI endpoint framework populates the directory with the common
+configurable fields::
+
+ # ls functions/pci_epf_dma/dma0
+ baseclass_code msi_interrupts progif_code subsys_id
+ cache_line_size msix_interrupts revid subsys_vendor_id
+ deviceid pci_epf_dma.0 secondary vendorid
+ interrupt_pin primary subclass_code
+
+The PCI DMA function driver also creates a function-specific sub-directory.
+The numeric suffix depends on the endpoint function instance number::
+
+ # ls functions/pci_epf_dma/dma0/pci_epf_dma.0/
+ dma_window_bar metadata_bar rd_chans wr_chans
+
+Configuring pci-epf-dma Device
+------------------------------
+
+The host-side ``dw-edma-pcie`` PCI ID table does not contain a generic
+endpoint DMA PCI ID entry. Choose a PCI vendor/device ID for the endpoint
+device::
+
+ # echo <vendor-id> > functions/pci_epf_dma/dma0/vendorid
+ # echo <device-id> > functions/pci_epf_dma/dma0/deviceid
+ # echo 1 > functions/pci_epf_dma/dma0/msi_interrupts
+
+The PCI class defaults to ``PCI_BASE_CLASS_SYSTEM`` and
+``PCI_CLASS_SYSTEM_DMA``.
+
+The function-specific attributes are:
+
+============== ============================================================
+Attribute Description
+============== ============================================================
+metadata_bar BAR used to publish the endpoint DMA metadata and handshake
+ bits. It is kept as a stable BAR while the DMA windows are
+ programmed. If this is left unset, the first usable BAR that
+ does not already contain a fixed DMA resource is used.
+dma_window_bar BAR used for DMA resources that are not already host-visible,
+ such as the DMA register window or descriptor windows. This
+ BAR may be switched to subrange mapping after the host driver
+ has found the metadata. If this is left unset and a DMA
+ window is needed, the first usable BAR different from
+ ``metadata_bar`` and not already occupied by a fixed DMA
+ resource is used.
+wr_chans Number of endpoint-to-RC DMA write channels to expose.
+rd_chans Number of RC-to-endpoint DMA read channels to expose.
+============== ============================================================
+
+A sample configuration for a DesignWare eDMA/HDMA compatible controller with
+two write channels and two read channels is given below::
+
+ # echo 0 > functions/pci_epf_dma/dma0/pci_epf_dma.0/metadata_bar
+ # echo 2 > functions/pci_epf_dma/dma0/pci_epf_dma.0/dma_window_bar
+ # echo 2 > functions/pci_epf_dma/dma0/pci_epf_dma.0/wr_chans
+ # echo 2 > functions/pci_epf_dma/dma0/pci_epf_dma.0/rd_chans
+
+``wr_chans`` and ``rd_chans`` default to 0. At least one channel direction
+must be configured. The selected channels are exposed in dense, zero-based
+order; for example, ``wr_chans = 2`` exposes write channels 0 and 1.
+DesignWare eDMA unroll and HDMA compatible layouts require each exposed
+direction to be delegated as a whole, so set a direction to either 0 or the
+number of hardware channels in that direction. DesignWare HDMA native
+linked-list mode allows a smaller dense prefix. If ``dma_window_bar`` is
+configured, it must be different from ``metadata_bar``.
+
+The common ``msi_interrupts`` and ``msix_interrupts`` attributes select the
+number of MSI and MSI-X vectors exposed to the host. At least one MSI or
+MSI-X vector must be configured.
+
+The function-specific attributes can only be changed before the endpoint
+function is bound to an endpoint controller.
+
+Binding pci-epf-dma Device to EP Controller
+-------------------------------------------
+
+The DMA function device should be attached to a PCI endpoint controller
+connected to the host::
+
+ # ln -s controllers/e65d0000.pcie-ep \
+ functions/pci_epf_dma/dma0/primary/
+
+Once the above step is completed, the PCI endpoint controller is ready to
+establish a link with the host.
+
+Start the Link
+--------------
+
+Start the endpoint controller by writing 1 to ``start``::
+
+ # echo 1 > controllers/e65d0000.pcie-ep/start
+
+Root Complex Device
+===================
+
+lspci Output
+------------
+
+Note that the device listed here corresponds to the values populated in the
+endpoint configuration above::
+
+ # lspci -nk
+ 01:00.1 0801: <vendor-id>:<device-id>
+
+If the host was already running while the endpoint function was configured,
+rescan the PCI bus after the endpoint side has completed the configfs setup
+and started the endpoint controller, if the platform supports it.
+
+Bind the endpoint DMA function to ``dw-edma-pcie`` explicitly with
+``driver_override``::
+
+ # modprobe dw_edma_pcie
+ # echo dw-edma-pcie > /sys/bus/pci/devices/0000:01:00.1/driver_override
+ # echo 0000:01:00.1 > /sys/bus/pci/drivers_probe
+
+The device should then be bound to ``dw-edma-pcie``::
+
+ # lspci -nk -s 01:00.1
+ 01:00.1 0801: <vendor-id>:<device-id>
+ Kernel driver in use: dw-edma-pcie
+
+Using pci-epf-dma Device
+------------------------
+
+The host side software uses the standard Linux DMAengine API. A DMAengine
+client driver running on the host must request one of the channels provided by
+``dw-edma-pcie`` and submit a transfer.
+
+For an endpoint-to-RC write transfer, the DMAengine client uses a host DMA
+buffer as the destination and an endpoint-side address as the slave source
+address. For an RC-to-endpoint read transfer, the DMAengine client uses a
+host DMA buffer as the source and an endpoint-side address as the slave
+destination address.
+
+Troubleshooting
+===============
+
+``pci-epf-dma`` requires endpoint controller support for DMA auxiliary
+resources and MSI or MSI-X. If any DMA resource must be mapped dynamically,
+the endpoint controller must also support BAR subrange mapping and dynamic
+inbound mapping. Binding the function to an endpoint controller fails if the
+required capabilities are not available, or if both ``msi_interrupts`` and
+``msix_interrupts`` are zero.
+
+If ``dw-edma-pcie`` fails to probe on the host, check that the endpoint was
+bound to the host driver, that the endpoint BARs were assigned by PCI
+enumeration, and that the endpoint DMA metadata READY bit was set after any
+DMA window BAR submaps were programmed.
--
2.51.0
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function
2026-08-13 6:37 [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Koichiro Den
` (9 preceding siblings ...)
2026-08-13 6:37 ` [PATCH v7 10/10] Documentation: PCI: Add PCI DMA endpoint function documentation Koichiro Den
@ 2026-08-13 11:46 ` Niklas Cassel
2026-08-13 12:50 ` Manivannan Sadhasivam
10 siblings, 1 reply; 25+ messages in thread
From: Niklas Cassel @ 2026-08-13 11:46 UTC (permalink / raw)
To: Koichiro Den
Cc: Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Frank Li, Bjorn Helgaas, Jonathan Corbet,
Shuah Khan, Randy Dunlap, Vinod Koul, Jingoo Han,
Lorenzo Pieralisi, Rob Herring, Damien Le Moal, Arnd Bergmann,
Marek Vasut, Yoshihiro Shimoda, linux-pci, linux-doc,
linux-kernel, dmaengine
Hello Koichiro,
On Thu, Aug 13, 2026 at 03:37:47PM +0900, Koichiro Den wrote:
> This is v7, the remaining patch set for PCI endpoint DMA.
> Parts 2 and 3 were merged per Frank's suggestion.
(snip)
> One open question is how to support endpoint controllers with only one
> PF. Keeping DMA in a separate EPF requires multi-function endpoint
> support. Folding it into vNTB would work on single-function
> controllers, but would also couple the two implementations. This series
> keeps the separate EPF model.
I see all the work you are putting in and I admire the effort.
This is now v7. I think it is time that we close the open question by
waiting for a reply from the PCI endpoint maintainers' opinion on the
design before continuing. (I am not a PCI endpoint maintainer.)
I understand that you want a common DMA abstraction, that can represent
different (embedded) DMA controllers on the endpoint side.
But if vNTB is the only consumer of this, then why not simply embed this
DMA abstraction in some BAR exposed by the vNTB EPF?
Looking at the host side driver that goes with the (v)NTB driver:
drivers/ntb/hw/epf/ntb_hw_epf.c
The BAR layouts are hard coded, and it only supports three different
layouts. Would it not be possible to add a fourth layout that has the
DMA abstraction somewhere in one of the BARs? ('BAR_DMA' ?)
Right now, I wonder if it is not a bit premature optimization to create a
DMA EPF, if vNTB will be the only (ever?) user.
I didn't follow all the details, but I know that you want to control the
DMA controller on the endpoint from the host side. Is this really a
normal use case outside of vNTB? I would imagine that most endpoints
will read some ring buffer of descriptors, perform some validation on
those descriptors, and then decide if it will do DMA to/from the host.
If the host side driver want to make use of your "generic DMA registers",
then you are basically creating another DMA controller? Shouldn't you
then create a new host side driver specifically for this "generic DMA
controller"? It would be nice if you could explain a bit better why you are
bothering to create a "generic DMA layout", but then you are reusing the
dw-edma-pcie driver. This seems a bit weird to me.
Right now you seem to "unpack" the "generic DMA layout" in a dw-edma specific
function: dw_edma_pcie_validate_ep_dma_metadata().
If you want this encapsulation, shouldn't the de-encapsulation be done by a
host side "DMA EPF" driver, and then this generic driver will then call
e.g. dw_edma_probe(). (Seems wrong to add de-encapsulation code in dw-edma
for your own made up format. And then all DMA drivers would need to do this
same de-encapsulation.)
Currently, I know R-Car 4 has an EPC controller that supports multi-function,
but I personally don't know any other. If you could embed your DMA abstraction
somewhere in one of the vNTB BARs, that would avoid the multi-function problem,
so your solution would not be limited to EPC controllers that only supports
multi-function.
Kind regards,
Niklas
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function
2026-08-13 11:46 ` [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function Niklas Cassel
@ 2026-08-13 12:50 ` Manivannan Sadhasivam
2026-08-13 14:15 ` Koichiro Den
0 siblings, 1 reply; 25+ messages in thread
From: Manivannan Sadhasivam @ 2026-08-13 12:50 UTC (permalink / raw)
To: Niklas Cassel
Cc: Koichiro Den, Krzysztof Wilczyński, Kishon Vijay Abraham I,
Frank Li, Bjorn Helgaas, Jonathan Corbet, Shuah Khan,
Randy Dunlap, Vinod Koul, Jingoo Han, Lorenzo Pieralisi,
Rob Herring, Damien Le Moal, Arnd Bergmann, Marek Vasut,
Yoshihiro Shimoda, linux-pci, linux-doc, linux-kernel, dmaengine
On Thu, Aug 13, 2026 at 01:46:07PM +0200, Niklas Cassel wrote:
> Hello Koichiro,
>
> On Thu, Aug 13, 2026 at 03:37:47PM +0900, Koichiro Den wrote:
> > This is v7, the remaining patch set for PCI endpoint DMA.
> > Parts 2 and 3 were merged per Frank's suggestion.
>
> (snip)
>
> > One open question is how to support endpoint controllers with only one
> > PF. Keeping DMA in a separate EPF requires multi-function endpoint
> > support. Folding it into vNTB would work on single-function
> > controllers, but would also couple the two implementations. This series
> > keeps the separate EPF model.
>
> I see all the work you are putting in and I admire the effort.
>
> This is now v7. I think it is time that we close the open question by
> waiting for a reply from the PCI endpoint maintainers' opinion on the
> design before continuing. (I am not a PCI endpoint maintainer.)
>
> I understand that you want a common DMA abstraction, that can represent
> different (embedded) DMA controllers on the endpoint side.
>
> But if vNTB is the only consumer of this, then why not simply embed this
> DMA abstraction in some BAR exposed by the vNTB EPF?
>
> Looking at the host side driver that goes with the (v)NTB driver:
> drivers/ntb/hw/epf/ntb_hw_epf.c
>
> The BAR layouts are hard coded, and it only supports three different
> layouts. Would it not be possible to add a fourth layout that has the
> DMA abstraction somewhere in one of the BARs? ('BAR_DMA' ?)
>
>
> Right now, I wonder if it is not a bit premature optimization to create a
> DMA EPF, if vNTB will be the only (ever?) user.
>
Yeah, I feel the same. I haven't seen an usecase to program the DMA controller
from the host outside of vNTB. This feature is supported mostly because it
exists in hardware and someone wants to tick the checkbox.
Though, I'm not against doing it within vNTB as Niklas suggested, but
generalising it in the form of a new EPF driver just for the sake of a single
driver sounds like an overkill and maintenance burden.
Sorry for saying this in v7. I've been meaning to say it, but somehow ended up
procrastinating too much.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function
2026-08-13 12:50 ` Manivannan Sadhasivam
@ 2026-08-13 14:15 ` Koichiro Den
2026-08-13 15:59 ` Frank Li
0 siblings, 1 reply; 25+ messages in thread
From: Koichiro Den @ 2026-08-13 14:15 UTC (permalink / raw)
To: Manivannan Sadhasivam, Niklas Cassel
Cc: Krzysztof Wilczyński, Kishon Vijay Abraham I, Frank Li,
Bjorn Helgaas, Jonathan Corbet, Shuah Khan, Randy Dunlap,
Vinod Koul, Jingoo Han, Lorenzo Pieralisi, Rob Herring,
Damien Le Moal, Arnd Bergmann, Marek Vasut, Yoshihiro Shimoda,
linux-pci, linux-doc, linux-kernel, dmaengine
On Thu, Aug 13, 2026 at 02:50:59PM +0200, Manivannan Sadhasivam wrote:
> On Thu, Aug 13, 2026 at 01:46:07PM +0200, Niklas Cassel wrote:
> > Hello Koichiro,
> >
> > On Thu, Aug 13, 2026 at 03:37:47PM +0900, Koichiro Den wrote:
> > > This is v7, the remaining patch set for PCI endpoint DMA.
> > > Parts 2 and 3 were merged per Frank's suggestion.
> >
> > (snip)
> >
> > > One open question is how to support endpoint controllers with only one
> > > PF. Keeping DMA in a separate EPF requires multi-function endpoint
> > > support. Folding it into vNTB would work on single-function
> > > controllers, but would also couple the two implementations. This series
> > > keeps the separate EPF model.
> >
> > I see all the work you are putting in and I admire the effort.
> >
> > This is now v7. I think it is time that we close the open question by
> > waiting for a reply from the PCI endpoint maintainers' opinion on the
> > design before continuing. (I am not a PCI endpoint maintainer.)
> >
> > I understand that you want a common DMA abstraction, that can represent
> > different (embedded) DMA controllers on the endpoint side.
> >
> > But if vNTB is the only consumer of this, then why not simply embed this
> > DMA abstraction in some BAR exposed by the vNTB EPF?
> >
> > Looking at the host side driver that goes with the (v)NTB driver:
> > drivers/ntb/hw/epf/ntb_hw_epf.c
> >
> > The BAR layouts are hard coded, and it only supports three different
> > layouts. Would it not be possible to add a fourth layout that has the
> > DMA abstraction somewhere in one of the BARs? ('BAR_DMA' ?)
> >
> >
> > Right now, I wonder if it is not a bit premature optimization to create a
> > DMA EPF, if vNTB will be the only (ever?) user.
> >
>
> Yeah, I feel the same. I haven't seen an usecase to program the DMA controller
> from the host outside of vNTB. This feature is supported mostly because it
> exists in hardware and someone wants to tick the checkbox.
>
> Though, I'm not against doing it within vNTB as Niklas suggested, but
> generalising it in the form of a new EPF driver just for the sake of a single
> driver sounds like an overkill and maintenance burden.
>
> Sorry for saying this in v7. I've been meaning to say it, but somehow ended up
> procrastinating too much.
No bother. Since Frank has given a lot of feedback on this series, I'd also like
to hear his view.
I'm fine with either direction, and can revisit the earlier vNTB-embedded
approach:
https://lore.kernel.org/r/sn67hi7kljh7cgmgodatb3naz2astlaklqfobdbxyyzgoohxqb@4nnetbhqwba4/
Best regards,
Koichiro
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH v7 00/10] PCI: endpoint: Add PCI DMA endpoint function
2026-08-13 14:15 ` Koichiro Den
@ 2026-08-13 15:59 ` Frank Li
0 siblings, 0 replies; 25+ messages in thread
From: Frank Li @ 2026-08-13 15:59 UTC (permalink / raw)
To: Koichiro Den
Cc: Manivannan Sadhasivam, Niklas Cassel, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Frank Li, Bjorn Helgaas, Jonathan Corbet,
Shuah Khan, Randy Dunlap, Vinod Koul, Jingoo Han,
Lorenzo Pieralisi, Rob Herring, Damien Le Moal, Arnd Bergmann,
Marek Vasut, Yoshihiro Shimoda, linux-pci, linux-doc,
linux-kernel, dmaengine
On Thu, Aug 13, 2026 at 11:15:31PM +0900, Koichiro Den wrote:
> On Thu, Aug 13, 2026 at 02:50:59PM +0200, Manivannan Sadhasivam wrote:
> > On Thu, Aug 13, 2026 at 01:46:07PM +0200, Niklas Cassel wrote:
> > > Hello Koichiro,
> > >
> > > On Thu, Aug 13, 2026 at 03:37:47PM +0900, Koichiro Den wrote:
> > > > This is v7, the remaining patch set for PCI endpoint DMA.
> > > > Parts 2 and 3 were merged per Frank's suggestion.
> > >
> > > (snip)
> > >
> > > > One open question is how to support endpoint controllers with only one
> > > > PF. Keeping DMA in a separate EPF requires multi-function endpoint
> > > > support. Folding it into vNTB would work on single-function
> > > > controllers, but would also couple the two implementations. This series
> > > > keeps the separate EPF model.
> > >
> > > I see all the work you are putting in and I admire the effort.
> > >
> > > This is now v7. I think it is time that we close the open question by
> > > waiting for a reply from the PCI endpoint maintainers' opinion on the
> > > design before continuing. (I am not a PCI endpoint maintainer.)
> > >
> > > I understand that you want a common DMA abstraction, that can represent
> > > different (embedded) DMA controllers on the endpoint side.
> > >
> > > But if vNTB is the only consumer of this, then why not simply embed this
> > > DMA abstraction in some BAR exposed by the vNTB EPF?
> > >
> > > Looking at the host side driver that goes with the (v)NTB driver:
> > > drivers/ntb/hw/epf/ntb_hw_epf.c
> > >
> > > The BAR layouts are hard coded, and it only supports three different
> > > layouts. Would it not be possible to add a fourth layout that has the
> > > DMA abstraction somewhere in one of the BARs? ('BAR_DMA' ?)
> > >
> > >
> > > Right now, I wonder if it is not a bit premature optimization to create a
> > > DMA EPF, if vNTB will be the only (ever?) user.
> > >
> >
> > Yeah, I feel the same. I haven't seen an usecase to program the DMA controller
> > from the host outside of vNTB. This feature is supported mostly because it
> > exists in hardware and someone wants to tick the checkbox.
> >
> > Though, I'm not against doing it within vNTB as Niklas suggested, but
> > generalising it in the form of a new EPF driver just for the sake of a single
> > driver sounds like an overkill and maintenance burden.
> >
> > Sorry for saying this in v7. I've been meaning to say it, but somehow ended up
> > procrastinating too much.
>
> No bother. Since Frank has given a lot of feedback on this series, I'd also like
> to hear his view.
>
> I'm fine with either direction, and can revisit the earlier vNTB-embedded
> approach:
> https://lore.kernel.org/r/sn67hi7kljh7cgmgodatb3naz2astlaklqfobdbxyyzgoohxqb@4nnetbhqwba4/
One of the important value is test dw-edma-pcie.c, which generally depend
on some fpga hardware. If there are epf driver work as fpga hardware, it
will help cover edma remote user case. So more user can test it.
Of course, this implement are over complex. I suggest update dma-engine
chan_id to support static allocate, which also need be fixed because
some drivers have such dependence, anyway need be fixed. After this fix,
this patches will become simpler.
VNTB case, it'd better put such informaiton into one BARs and work on
single-function.
I suggest split two things
1 - create simple epf driver to test dw-edma-pcie.c.
2 - vntb support DMA.
of course, if shared efforts, it will be great.
Frank
>
> Best regards,
> Koichiro
>
> >
> > - Mani
> >
> > --
> > மணிவண்ணன் சதாசிவம்
^ permalink raw reply [flat|nested] 25+ messages in thread