On Wed, Feb 04, 2026 at 02:39:03PM -0500, Frank Li wrote:

On Wed, Feb 04, 2026 at 11:54:29PM +0900, Koichiro Den wrote:

quoted

Remote DMA users may need to map or otherwise correlate DMA resources on
a per-hardware-channel basis (e.g. DWC EP eDMA linked-list windows).
However, struct dma_chan does not expose a provider-defined hardware
channel identifier.

Add an optional dma_slave_caps.hw_id field to allow DMA engine drivers
to report a provider-specific hardware channel identifier to clients.
Initialize the field to -1 in dma_get_slave_caps() so drivers that do
not populate it continue to behave as before.

Signed-off-by: Koichiro Den <redacted>
---
 drivers/dma/dmaengine.c   | 1 +
 include/linux/dmaengine.h | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index ca13cd39330b..b544eb99359d 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c

@@ -603,6 +603,7 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
 	caps->cmd_pause = !!device->device_pause;
 	caps->cmd_resume = !!device->device_resume;
 	caps->cmd_terminate = !!device->device_terminate_all;
+	caps->hw_id = -1;

 	/*
 	 * DMA engine device might be configured with non-uniformly

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 99efe2b9b4ea..71bc2674567f 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h

@@ -507,6 +507,7 @@ enum dma_residue_granularity {
  * @residue_granularity: granularity of the reported transfer residue
  * @descriptor_reuse: if a descriptor can be reused by client and
  * resubmitted multiple times
+ * @hw_id: provider-specific hardware channel identifier (-1 if unknown)
  */
 struct dma_slave_caps {
 	u32 src_addr_widths;

@@ -520,6 +521,7 @@ struct dma_slave_caps {
 	bool cmd_terminate;
 	enum dma_residue_granularity residue_granularity;
 	bool descriptor_reuse;
+	int hw_id;

I have not see where use it? Does src_id of struct dma_chan work?

There is no direct user of hw_id in this series. The intended flow is:
  1. obtain dma channels to expose via the standard dma_request_channel()
  2. get 'hw_id' for each obtained channel (with this patch, Patch v3 1/11)
  3. call the pci_epc_get_remote_resources() API (introduced in Patch v3 6/11)
  4. iterate the resource list obtained in step 3, and find a resource whose
     .type is PCI_EPC_RR_DMA_CHAN_DESC and .u.dma_chan_desc.hw_chan_id
     matches 'hw_id' obtained in step 2.

By the way, I couldn't find any 'src_id' field in struct dma_chan.
Did you mean dma_chan.chan_id? If so, it's explicitly a sysfs ID and is
allocated by the dmaengine core (from dma_device->chan_ida), so it doesn't
correlate with the provider's HW channel numbering.

(Also, correction to my note in the previous v2 thread:
 https://lore.kernel.org/all/zqcu3awadvqbtil3vudcmgjyjpku7divrhqyox72k43nfzcoo7@hflaengfjy27/ (local)
 There I wrote that the low-level dma channel id would become unnecessary,
 but that was incorrect because dma_request_channel() does not provide any
 guarantee that channels are allocated in hw channel order: other,
 unrelated components may have requested dma channels earlier or in
 parallel, so the set of channels obtained by a given user cannot be
 assumed to map cleanly to hw-level channel IDs starting from 0. So this v3 still
 includes this patch. That said, since there are no direct users in this
 series, I am open to dropping Patch v3 1/11-2/11 if you think that would
 be preferable.)

Thanks,
Koichiro

Frank

quoted

 };

 static inline const char *dma_chan_name(struct dma_chan *chan)
--
2.51.0