linux-kernel - Re: [PATCH v3 01/11] dmaengine: Add hw_id to dma_slave

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f3byxj7aup6sixkxixtayamh4m6q3df77rweiawbmmtcsw4boh@vbfbjhufe45r>
Date: Thu, 5 Feb 2026 15:46:37 +0900
From: Koichiro Den <den@...inux.co.jp>
To: Frank Li <Frank.li@....com>
Cc: vkoul@...nel.org, mani@...nel.org, jingoohan1@...il.com, 
	lpieralisi@...nel.org, kwilczynski@...nel.org, robh@...nel.org, bhelgaas@...gle.com, 
	dmaengine@...r.kernel.org, linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 01/11] dmaengine: Add hw_id to dma_slave_caps

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@...inux.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
> >