Re: [PATCH 5/9] dmaengine: stm32-dma3: Use bus width capability helpers

On Thu, Jul 30, 2026 at 02:35:28PM +0000, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Direct return on error from `dma_set_src_bus_widths()` or `dma_set_dst_bus_widths()` bypasses clock cleanup, causing a resource leak.
> --

Yeps! This needs fixing in v2.

- Nuno Sá

> 
> --- Patch [5]: [PATCH 5/9] dmaengine: stm32-dma3: Use bus width capability helpers ---
> Please note that the format of this report has been altered due to recitation
> restrictions. The original patch code is not quoted directly, and findings are
> summarized in a free-form text format.
> 
> commit 843bd75e7b8b643c8fda123b493184a039d48a35
> Author: Nuno Sá <[email protected]>
> 
> dmaengine: stm32-dma3: Use bus width capability helpers
> 
> This commit advertises the controller-wide bus width capabilities through the
> new dma_set_src_bus_widths() and dma_set_dst_bus_widths() helpers. It also
> updates the per-channel capability callback to clear unsupported widths
> through the dma_slave_caps helpers.
> 
> [Severity: Medium]
> In the stm32_dma3_probe() function, the patch adds calls to
> dma_set_src_bus_widths() and dma_set_dst_bus_widths(). If either of these
> helper functions returns an error, the code now does a direct return with the
> error code.
> 
> Does this direct return bypass the clock cleanup? 
> 
> Earlier in the probe function, the clock is prepared and enabled via
> clk_prepare_enable(ddata->clk). If an error occurs later, the normal error
> handling path is to goto err_clk_disable to ensure the clock is properly
> disabled. Returning directly here leaves the hardware clock prepared and
> enabled, causing a resource leak.
> 
> Should these return statements be changed to goto err_clk_disable instead?
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260730-dmaengine-support-wider-dma-masks-v1-0-3732f1f9d9ca@analog.com?part=5