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

[sashiko-bot@kernel.org]

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

--- 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á <nuno.sa@analog.com>

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