linux-kernel - Re: [PATCH 2/2] dmaengine: dw-axi-dmac: add reset control support

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] [day] [month] [year] [list]

Message-ID: <bf59e192acc06c88f122578e40ee64e1cafe8152.camel@pengutronix.de>
Date: Mon, 13 Oct 2025 10:41:45 +0200
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Artem Shimko <a.shimko.dev@...il.com>, Eugeniy Paltsev
	 <Eugeniy.Paltsev@...opsys.com>, Vinod Koul <vkoul@...nel.org>
Cc: dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] dmaengine: dw-axi-dmac: add reset control support

On So, 2025-10-12 at 13:00 +0300, Artem Shimko wrote:
> Add proper reset control handling to the AXI DMA driver to ensure
> reliable initialization and power management. The driver now manages
> resets during probe, remove, and system suspend/resume operations.
> 
> The implementation stores reset control in the chip structure and adds
> reset assert/deassert calls at the appropriate points: resets are
> deasserted during probe after clock acquisition, asserted during remove
> and error cleanup, and properly managed during suspend/resume cycles.
> Additionally, proper error handling is implemented for reset control
> operations to ensure robust behavior.
> 
> This ensures the controller is properly reset during power transitions
> and prevents potential issues with incomplete initialization.
> 
> Signed-off-by: Artem Shimko <a.shimko.dev@...il.com>
> ---
>  .../dma/dw-axi-dmac/dw-axi-dmac-platform.c    | 41 ++++++++++++-------
>  drivers/dma/dw-axi-dmac/dw-axi-dmac.h         |  2 +
>  2 files changed, 28 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> index 8b7cf3baf5d3..3f4dd2178498 100644
> --- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> +++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> @@ -1321,6 +1321,9 @@ static int axi_dma_suspend(struct device *dev)
>  	axi_dma_irq_disable(chip);
>  	axi_dma_disable(chip);
>  
> +	if (chip->has_resets)
> +		reset_control_assert(chip->resets);

reset_control_assert/deassert() handle NULL pointers, so you could drop
the chip->has_resets flag and just

	reset_control_assert(chip->resets);

unconditionally.

> +
>  	clk_disable_unprepare(chip->core_clk);
>  	clk_disable_unprepare(chip->cfgr_clk);
>  
> @@ -1340,6 +1343,9 @@ static int axi_dma_resume(struct device *dev)
>  	if (ret < 0)
>  		return ret;
>  
> +	if (chip->has_resets)
> +		reset_control_deassert(chip->resets);
> +

Same as above.

>  	axi_dma_enable(chip);
>  	axi_dma_irq_enable(chip);
>  
> @@ -1455,7 +1461,6 @@ static int dw_probe(struct platform_device *pdev)
>  	struct axi_dma_chip *chip;
>  	struct dw_axi_dma *dw;
>  	struct dw_axi_dma_hcfg *hdata;
> -	struct reset_control *resets;
>  	unsigned int flags;
>  	u32 i;
>  	int ret;
> @@ -1487,16 +1492,6 @@ static int dw_probe(struct platform_device *pdev)
>  			return PTR_ERR(chip->apb_regs);
>  	}
>  
> -	if (flags & AXI_DMA_FLAG_HAS_RESETS) {
> -		resets = devm_reset_control_array_get_exclusive(&pdev->dev);
> -		if (IS_ERR(resets))
> -			return PTR_ERR(resets);
> -
> -		ret = reset_control_deassert(resets);
> -		if (ret)
> -			return ret;
> -	}
> -
>  	chip->dw->hdata->use_cfg2 = !!(flags & AXI_DMA_FLAG_USE_CFG2);
>  
>  	chip->core_clk = devm_clk_get(chip->dev, "core-clk");
> @@ -1507,18 +1502,31 @@ static int dw_probe(struct platform_device *pdev)
>  	if (IS_ERR(chip->cfgr_clk))
>  		return PTR_ERR(chip->cfgr_clk);
>  
> +	chip->has_resets = !!(flags & AXI_DMA_FLAG_HAS_RESETS);
> +	if (chip->has_resets) {
> +		chip->resets = devm_reset_control_array_get_exclusive(&pdev->dev);
> +		if (IS_ERR(chip->resets))
> +			return PTR_ERR(chip->resets);
> +
> +		ret = reset_control_deassert(chip->resets);
> +		if (ret)
> +			return dev_err_probe(&pdev->dev, ret, "Failed to deassert resets\n");
> +	}
> +

Why is this moved down here?

>  	ret = parse_device_properties(chip);
>  	if (ret)
> -		return ret;
> +		goto err_exit;
>  
>  	dw->chan = devm_kcalloc(chip->dev, hdata->nr_channels,
>  				sizeof(*dw->chan), GFP_KERNEL);
> -	if (!dw->chan)
> -		return -ENOMEM;
> +	if (!dw->chan) {
> +		ret = -ENOMEM;
> +		goto err_exit;
> +	}
>  
>  	ret = axi_req_irqs(pdev, chip);
>  	if (ret)
> -		return ret;
> +		goto err_exit;
>  
>  	INIT_LIST_HEAD(&dw->dma.channels);
>  	for (i = 0; i < hdata->nr_channels; i++) {
> @@ -1605,6 +1613,9 @@ static int dw_probe(struct platform_device *pdev)
>  
>  err_pm_disable:
>  	pm_runtime_disable(chip->dev);
> +err_exit:
> +	if (chip->has_resets)
> +		reset_control_assert(chip->resets);

If it is ok to keep the module in reset, shouldn't the reset control be
asserted on device remove() as well?

regards
Philipp