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 <den@valinux.co.jp>
---
 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;
 };
 
 static inline const char *dma_chan_name(struct dma_chan *chan)
-- 
2.51.0

On Wed, Feb 04, 2026 at 11:54:29PM +0900, Koichiro Den wrote:
> 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 <den@valinux.co.jp>
> ---
>  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?

Frank

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

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:
> > 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 <den@valinux.co.jp>
> > ---
> >  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/
 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
> 
> >  };
> >
> >  static inline const char *dma_chan_name(struct dma_chan *chan)
> > --
> > 2.51.0
> >

On Thu, Feb 05, 2026 at 03:46:37PM +0900, Koichiro Den wrote:
> 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:
> > > 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 <den@valinux.co.jp>
> > > ---
> > >  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.

Yes, I think it'd better to align HW channel numberring, we should extent
API to allow set it to hardware id or add hw_id in struct dma_chan.

hw_id is not caps.

>
> (Also, correction to my note in the previous v2 thread:
>  https://lore.kernel.org/all/zqcu3awadvqbtil3vudcmgjyjpku7divrhqyox72k43nfzcoo7@hflaengfjy27/
>  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.)

I think struct dma_chan should carry hardware id information.

Frank
>
> Thanks,
> Koichiro
>
> >
> > Frank
> >
> > >  };
> > >
> > >  static inline const char *dma_chan_name(struct dma_chan *chan)
> > > --
> > > 2.51.0
> > >