Re: [PATCH v3 01/11] dmaengine: Add hw_id to dma_slave_caps

[Frank Li <Frank.li@nxp.com>]

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
> > >