[PATCH 0/2] Add DMA devlink support

[PATCH 0/2] Add DMA devlink support

[Marco Felsch]

Hi,

this is a new series which was previously part of [1].

While debugging the i.MX SDMA driver we noticed that the driver doesn't
honor current active DMA users. So the supplier (dmaengine) driver can
be removed before the users are removed. This cause use-after-frees
failures and the whole system is frozen.

To address this the Linux devlink support is added to the dmaengine
framework. This series uses the managed devlink support which ensures
that the users are removed first before the supplier is removed, which
is the main goal of this series.

Managed devlinks require that both link devices are backed by a driver
(of course). Therefore this series uses the dmaengine device as devlink
supplier device and _not_ the dma-channel devices. The dma-channel
devices are virtual devices which don't have a driver.

Frank Li already mentioned that dma-channel devices should be used to
gain a more fine grained runtime-PM support, e.g. to control clocks for
each DMA channel. This would require the devlink to be STATELESS.
Stateless devlinks don't ensure the correct device remove order (main
goal of this series).

Having a more fine grained runtime-PM support (for each channel) is
valid, but IMHO this is rather an addition to this series. The support
for this use-case requires that the dma_devclass implements the .pm
hook. This hook would need to call into the dmaengine driver to perform
runtime-PM on the dedicated channel. This also requires a HW which
supports clock gating for each DMA channel.

Regards,
  Marco

[1] https://lore.kernel.org/r/20250903-v6-16-topic-sdma-v1-0-ac7bab629e8b@pengutronix.de

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
Changes in v2:
- Link to v1: https://lore.kernel.org/r/20250903-v6-16-topic-sdma-v1-0-ac7bab629e8b@pengutronix.de
- Split series into SDMA cleanup&fixes and this DMA devlink support
- Add dmaegine flag to create the devlinks
- Update the kernel doc
- Update commit message

---
Marco Felsch (2):
      dmaengine: add device_link support
      dmaengine: imx-sdma: fix supplier/consumer dependency handling

 drivers/dma/dmaengine.c   | 15 +++++++++++++++
 drivers/dma/imx-sdma.c    | 15 +--------------
 include/linux/dmaengine.h |  3 +++
 3 files changed, 19 insertions(+), 14 deletions(-)
---
base-commit: 1b6bf726c96272139c2b20db3bee4c22c869a22b
change-id: 20250910-v6-16-topic-dma-devlink-00b803c5a803

Best regards,
-- 
Marco Felsch <m.felsch@pengutronix.de>

[PATCH 1/2] dmaengine: add device_link support

[Marco Felsch]

Shift the device dependency handling to the driver core by adding
support for devlinks.

The link between the consumer device and the dmaengine device is
established by the consumer via the dma_request_chan() automatically if
the dmaengine driver supports it (create_devlink flag set).

By adding the devlink support it is ensured that the supplier can't be
removed while the consumer still uses the dmaengine. Furthermore it
ensures that the supplier driver is present and actual bound before the
consumer is uses the supplier.

Additional PM and runtime-PM dependency handling can be added easily too
by setting the required flags (not implemented by this commit).

The new create_devlink flag controlls the devlink creation to not cause
any regressions with existing dmaengine drivers. This flag can be
removed once all drivers are successfully tested to support devlinks.

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
 drivers/dma/dmaengine.c   | 15 +++++++++++++++
 include/linux/dmaengine.h |  3 +++
 2 files changed, 18 insertions(+)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 758fcd0546d8bde8e8dddc6039848feeb1e24475..e81985ab806ae87ff3aa4739fe6f6328b2587f2e 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -858,6 +858,21 @@ struct dma_chan *dma_request_chan(struct device *dev, const char *name)
 	/* No functional issue if it fails, users are supposed to test before use */
 #endif
 
+	/*
+	 * Devlinks between the dmaengine device and the consumer device
+	 * are optional till all dmaengine drivers are converted/tested.
+	 */
+	if (chan->device->create_devlink) {
+		struct device_link *dl;
+
+		dl = device_link_add(dev, chan->device->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
+		if (!dl) {
+			dev_err(dev, "failed to create device link to %s\n",
+					dev_name(chan->device->dev));
+			return ERR_PTR(-EINVAL);
+		}
+	}
+
 	chan->name = kasprintf(GFP_KERNEL, "dma:%s", name);
 	if (!chan->name)
 		return chan;
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index bb146c5ac3e4ccd7bc0afbf3b28e5b3d659ad62f..c67737a358df659f2bf050a9ccb8d23b17ceb357 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -817,6 +817,8 @@ struct dma_filter {
  *	DMA tansaction with no software intervention for reinitialization.
  *	Zero value means unlimited number of entries.
  * @descriptor_reuse: a submitted transfer can be resubmitted after completion
+ * @create_devlink: create a devlink between a dma_chan_dev supplier and
+ *	dma-channel consumer device
  * @residue_granularity: granularity of the transfer residue reported
  *	by tx_status
  * @device_alloc_chan_resources: allocate resources and return the
@@ -894,6 +896,7 @@ struct dma_device {
 	u32 max_burst;
 	u32 max_sg_burst;
 	bool descriptor_reuse;
+	bool create_devlink;
 	enum dma_residue_granularity residue_granularity;
 
 	int (*device_alloc_chan_resources)(struct dma_chan *chan);

-- 
2.47.3

Re: [PATCH 1/2] dmaengine: add device_link support

[Frank Li]

On Fri, Sep 12, 2025 at 12:00:41AM +0200, Marco Felsch wrote:
> Shift the device dependency handling to the driver core by adding
> support for devlinks.
>
> The link between the consumer device and the dmaengine device is
> established by the consumer via the dma_request_chan() automatically if
> the dmaengine driver supports it (create_devlink flag set).
>
> By adding the devlink support it is ensured that the supplier can't be
> removed while the consumer still uses the dmaengine. Furthermore it
> ensures that the supplier driver is present and actual bound before the
> consumer is uses the supplier.
>
> Additional PM and runtime-PM dependency handling can be added easily too
> by setting the required flags (not implemented by this commit).
>
> The new create_devlink flag controlls the devlink creation to not cause
> any regressions with existing dmaengine drivers. This flag can be
> removed once all drivers are successfully tested to support devlinks.
>
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> ---

Add previous discussion link:
https://lore.kernel.org/all/aLhUv+mtr1uZTCth@lizhi-Precision-Tower-5810/

Another thread
https://lore.kernel.org/dmaengine/20250801120007.GB4906@pendragon.ideasonboard.com/

Add Laurent Pinchart, who may instest this topic also.

Add Rob Herring, who may know why dma engine can't create dev_link default
like other provider (clk, phy, gpio ...)


>  drivers/dma/dmaengine.c   | 15 +++++++++++++++
>  include/linux/dmaengine.h |  3 +++
>  2 files changed, 18 insertions(+)
>
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 758fcd0546d8bde8e8dddc6039848feeb1e24475..e81985ab806ae87ff3aa4739fe6f6328b2587f2e 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -858,6 +858,21 @@ struct dma_chan *dma_request_chan(struct device *dev, const char *name)
>  	/* No functional issue if it fails, users are supposed to test before use */
>  #endif
>
> +	/*
> +	 * Devlinks between the dmaengine device and the consumer device
> +	 * are optional till all dmaengine drivers are converted/tested.
> +	 */
> +	if (chan->device->create_devlink) {
> +		struct device_link *dl;
> +
> +		dl = device_link_add(dev, chan->device->dev, DL_FLAG_AUTOREMOVE_CONSUMER);

I suggest link to per channel device, instead dma engine devices.
chan->dev->device like phy drivers because some dma-engine have per channel
resources, like power domain and clocks.

Frank


> +		if (!dl) {
> +			dev_err(dev, "failed to create device link to %s\n",
> +					dev_name(chan->device->dev));
> +			return ERR_PTR(-EINVAL);
> +		}
> +	}
> +
>  	chan->name = kasprintf(GFP_KERNEL, "dma:%s", name);
>  	if (!chan->name)
>  		return chan;
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index bb146c5ac3e4ccd7bc0afbf3b28e5b3d659ad62f..c67737a358df659f2bf050a9ccb8d23b17ceb357 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -817,6 +817,8 @@ struct dma_filter {
>   *	DMA tansaction with no software intervention for reinitialization.
>   *	Zero value means unlimited number of entries.
>   * @descriptor_reuse: a submitted transfer can be resubmitted after completion
> + * @create_devlink: create a devlink between a dma_chan_dev supplier and
> + *	dma-channel consumer device
>   * @residue_granularity: granularity of the transfer residue reported
>   *	by tx_status
>   * @device_alloc_chan_resources: allocate resources and return the
> @@ -894,6 +896,7 @@ struct dma_device {
>  	u32 max_burst;
>  	u32 max_sg_burst;
>  	bool descriptor_reuse;
> +	bool create_devlink;
>  	enum dma_residue_granularity residue_granularity;
>
>  	int (*device_alloc_chan_resources)(struct dma_chan *chan);
>
> --
> 2.47.3
>

Re: [PATCH 1/2] dmaengine: add device_link support

[Laurent Pinchart]

On Thu, Sep 25, 2025 at 12:31:56PM -0400, Frank Li wrote:
> On Fri, Sep 12, 2025 at 12:00:41AM +0200, Marco Felsch wrote:
> > Shift the device dependency handling to the driver core by adding
> > support for devlinks.
> >
> > The link between the consumer device and the dmaengine device is
> > established by the consumer via the dma_request_chan() automatically if
> > the dmaengine driver supports it (create_devlink flag set).
> >
> > By adding the devlink support it is ensured that the supplier can't be
> > removed while the consumer still uses the dmaengine. Furthermore it
> > ensures that the supplier driver is present and actual bound before the
> > consumer is uses the supplier.

How is the latter ensured by this patch ? The link is created in
dma_request_chan() (which is called by the consumer), after successfully
obtaining the channel. I don't see how the link improves that mechanism.

> >
> > Additional PM and runtime-PM dependency handling can be added easily too
> > by setting the required flags (not implemented by this commit).

I've long thought that the DMA engine API should offer calls to "prepare"
and "unprepare" (names subject to bikeshedding) a DMA engine channel, so
that consumers can explicitly indicate when they are getting ready to
use DMA, and when they stop.

> >
> > The new create_devlink flag controlls the devlink creation to not cause
> > any regressions with existing dmaengine drivers. This flag can be
> > removed once all drivers are successfully tested to support devlinks.
> >
> > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > ---
> 
> Add previous discussion link:
> https://lore.kernel.org/all/aLhUv+mtr1uZTCth@lizhi-Precision-Tower-5810/
> 
> Another thread
> https://lore.kernel.org/dmaengine/20250801120007.GB4906@pendragon.ideasonboard.com/
> 
> Add Laurent Pinchart, who may instest this topic also.
> 
> Add Rob Herring, who may know why dma engine can't create dev_link default
> like other provider (clk, phy, gpio ...)
> 
> 
> >  drivers/dma/dmaengine.c   | 15 +++++++++++++++
> >  include/linux/dmaengine.h |  3 +++
> >  2 files changed, 18 insertions(+)
> >
> > diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> > index 758fcd0546d8bde8e8dddc6039848feeb1e24475..e81985ab806ae87ff3aa4739fe6f6328b2587f2e 100644
> > --- a/drivers/dma/dmaengine.c
> > +++ b/drivers/dma/dmaengine.c
> > @@ -858,6 +858,21 @@ struct dma_chan *dma_request_chan(struct device *dev, const char *name)
> >  	/* No functional issue if it fails, users are supposed to test before use */
> >  #endif
> >
> > +	/*
> > +	 * Devlinks between the dmaengine device and the consumer device
> > +	 * are optional till all dmaengine drivers are converted/tested.
> > +	 */
> > +	if (chan->device->create_devlink) {
> > +		struct device_link *dl;
> > +
> > +		dl = device_link_add(dev, chan->device->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
> 
> I suggest link to per channel device, instead dma engine devices.
> chan->dev->device like phy drivers because some dma-engine have per channel
> resources, like power domain and clocks.
> 
> Frank
> 
> > +		if (!dl) {
> > +			dev_err(dev, "failed to create device link to %s\n",
> > +					dev_name(chan->device->dev));
> > +			return ERR_PTR(-EINVAL);
> > +		}
> > +	}
> > +
> >  	chan->name = kasprintf(GFP_KERNEL, "dma:%s", name);
> >  	if (!chan->name)
> >  		return chan;
> > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > index bb146c5ac3e4ccd7bc0afbf3b28e5b3d659ad62f..c67737a358df659f2bf050a9ccb8d23b17ceb357 100644
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -817,6 +817,8 @@ struct dma_filter {
> >   *	DMA tansaction with no software intervention for reinitialization.
> >   *	Zero value means unlimited number of entries.
> >   * @descriptor_reuse: a submitted transfer can be resubmitted after completion
> > + * @create_devlink: create a devlink between a dma_chan_dev supplier and
> > + *	dma-channel consumer device
> >   * @residue_granularity: granularity of the transfer residue reported
> >   *	by tx_status
> >   * @device_alloc_chan_resources: allocate resources and return the
> > @@ -894,6 +896,7 @@ struct dma_device {
> >  	u32 max_burst;
> >  	u32 max_sg_burst;
> >  	bool descriptor_reuse;
> > +	bool create_devlink;
> >  	enum dma_residue_granularity residue_granularity;
> >
> >  	int (*device_alloc_chan_resources)(struct dma_chan *chan);
> >
> > --
> > 2.47.3
> >

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/2] dmaengine: add device_link support

[Frank Li]

On Mon, Oct 27, 2025 at 03:11:03AM +0200, Laurent Pinchart wrote:
> On Thu, Sep 25, 2025 at 12:31:56PM -0400, Frank Li wrote:
> > On Fri, Sep 12, 2025 at 12:00:41AM +0200, Marco Felsch wrote:
> > > Shift the device dependency handling to the driver core by adding
> > > support for devlinks.
> > >
> > > The link between the consumer device and the dmaengine device is
> > > established by the consumer via the dma_request_chan() automatically if
> > > the dmaengine driver supports it (create_devlink flag set).
> > >
> > > By adding the devlink support it is ensured that the supplier can't be
> > > removed while the consumer still uses the dmaengine. Furthermore it
> > > ensures that the supplier driver is present and actual bound before the
> > > consumer is uses the supplier.
>
> How is the latter ensured by this patch ? The link is created in
> dma_request_chan() (which is called by the consumer), after successfully
> obtaining the channel. I don't see how the link improves that mechanism.
>
> > >
> > > Additional PM and runtime-PM dependency handling can be added easily too
> > > by setting the required flags (not implemented by this commit).
>
> I've long thought that the DMA engine API should offer calls to "prepare"
> and "unprepare" (names subject to bikeshedding) a DMA engine channel, so
> that consumers can explicitly indicate when they are getting ready to
> use DMA, and when they stop.

This is one validate method. Maybe we set flags in dma_request_chan() to
indicate auto prepare when request chan to keep compatiblity with existed
drivers.

consumers who support prepare/unprepare can clean this flags at
dma_request_chan(). So we can smooth switch each consumer and dma-engine
driver to support this prepare/unprepare.

Frank

>
> > >
> > > The new create_devlink flag controlls the devlink creation to not cause
> > > any regressions with existing dmaengine drivers. This flag can be
> > > removed once all drivers are successfully tested to support devlinks.
> > >
> > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > > ---
> >
> > Add previous discussion link:
> > https://lore.kernel.org/all/aLhUv+mtr1uZTCth@lizhi-Precision-Tower-5810/
> >
> > Another thread
> > https://lore.kernel.org/dmaengine/20250801120007.GB4906@pendragon.ideasonboard.com/
> >
> > Add Laurent Pinchart, who may instest this topic also.
> >
> > Add Rob Herring, who may know why dma engine can't create dev_link default
> > like other provider (clk, phy, gpio ...)
> >
> >
> > >  drivers/dma/dmaengine.c   | 15 +++++++++++++++
> > >  include/linux/dmaengine.h |  3 +++
> > >  2 files changed, 18 insertions(+)
> > >
> > > diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> > > index 758fcd0546d8bde8e8dddc6039848feeb1e24475..e81985ab806ae87ff3aa4739fe6f6328b2587f2e 100644
> > > --- a/drivers/dma/dmaengine.c
> > > +++ b/drivers/dma/dmaengine.c
> > > @@ -858,6 +858,21 @@ struct dma_chan *dma_request_chan(struct device *dev, const char *name)
> > >  	/* No functional issue if it fails, users are supposed to test before use */
> > >  #endif
> > >
> > > +	/*
> > > +	 * Devlinks between the dmaengine device and the consumer device
> > > +	 * are optional till all dmaengine drivers are converted/tested.
> > > +	 */
> > > +	if (chan->device->create_devlink) {
> > > +		struct device_link *dl;
> > > +
> > > +		dl = device_link_add(dev, chan->device->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
> >
> > I suggest link to per channel device, instead dma engine devices.
> > chan->dev->device like phy drivers because some dma-engine have per channel
> > resources, like power domain and clocks.
> >
> > Frank
> >
> > > +		if (!dl) {
> > > +			dev_err(dev, "failed to create device link to %s\n",
> > > +					dev_name(chan->device->dev));
> > > +			return ERR_PTR(-EINVAL);
> > > +		}
> > > +	}
> > > +
> > >  	chan->name = kasprintf(GFP_KERNEL, "dma:%s", name);
> > >  	if (!chan->name)
> > >  		return chan;
> > > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > > index bb146c5ac3e4ccd7bc0afbf3b28e5b3d659ad62f..c67737a358df659f2bf050a9ccb8d23b17ceb357 100644
> > > --- a/include/linux/dmaengine.h
> > > +++ b/include/linux/dmaengine.h
> > > @@ -817,6 +817,8 @@ struct dma_filter {
> > >   *	DMA tansaction with no software intervention for reinitialization.
> > >   *	Zero value means unlimited number of entries.
> > >   * @descriptor_reuse: a submitted transfer can be resubmitted after completion
> > > + * @create_devlink: create a devlink between a dma_chan_dev supplier and
> > > + *	dma-channel consumer device
> > >   * @residue_granularity: granularity of the transfer residue reported
> > >   *	by tx_status
> > >   * @device_alloc_chan_resources: allocate resources and return the
> > > @@ -894,6 +896,7 @@ struct dma_device {
> > >  	u32 max_burst;
> > >  	u32 max_sg_burst;
> > >  	bool descriptor_reuse;
> > > +	bool create_devlink;
> > >  	enum dma_residue_granularity residue_granularity;
> > >
> > >  	int (*device_alloc_chan_resources)(struct dma_chan *chan);
> > >
> > > --
> > > 2.47.3
> > >
>
> --
> Regards,
>
> Laurent Pinchart

[PATCH 2/2] dmaengine: imx-sdma: fix supplier/consumer dependency handling

[Marco Felsch]

The whole driver was converted to the devm APIs except for this last
for-loop. This loop is buggy due to three reasons:
 1) It removes the channels without removing the users first. This can
    lead to very bad situations.
 2) The loop starts at 0 and which is channel0 which is a special
    control channel not registered via vchan_init(). Therefore the
    remove() always Oops because of NULL pointer exception.
 3) sdma_free_chan_resources() disable the clks unconditional without
    checking if the clks are enabled. This is done for all
    MAX_DMA_CHANNELS which hang the system if there is at least one unused
    channel.

The first issue is fixed by making use of the dmaengine devlink support.

The second issue is fixed by not doing anything on channel0.

The last issue is also fixed by the devlink support because during the
consumer teardown phase each requested channel is dropped accordingly so
the dmaengine driver doesn't need to this.

To sum-up, all issues are fixed by dropping the .remove() callback and
let the frameworks do their job.

Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
 drivers/dma/imx-sdma.c | 15 +--------------
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index d4430e6e56deda7de3538e42af7987a456957b43..a11317c8827297d1d6b8ddc0254ecf549e486001 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -2393,6 +2393,7 @@ static int sdma_probe(struct platform_device *pdev)
 	sdma->dma_device.device_prep_dma_memcpy = sdma_prep_memcpy;
 	sdma->dma_device.device_issue_pending = sdma_issue_pending;
 	sdma->dma_device.copy_align = 2;
+	sdma->dma_device.create_devlink = true;
 	dma_set_max_seg_size(sdma->dma_device.dev, SDMA_BD_MAX_CNT);
 
 	platform_set_drvdata(pdev, sdma);
@@ -2432,25 +2433,11 @@ static int sdma_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static void sdma_remove(struct platform_device *pdev)
-{
-	struct sdma_engine *sdma = platform_get_drvdata(pdev);
-	int i;
-
-	/* Kill the tasklet */
-	for (i = 0; i < MAX_DMA_CHANNELS; i++) {
-		struct sdma_channel *sdmac = &sdma->channel[i];
-
-		sdma_free_chan_resources(&sdmac->vc.chan);
-	}
-}
-
 static struct platform_driver sdma_driver = {
 	.driver		= {
 		.name	= "imx-sdma",
 		.of_match_table = sdma_dt_ids,
 	},
-	.remove		= sdma_remove,
 	.probe		= sdma_probe,
 };
 

-- 
2.47.3