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

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_s=
et_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 recitati=
on
restrictions. The original patch code is not quoted directly, and findings =
are
summarized in a free-form text format.

commit 843bd75e7b8b643c8fda123b493184a039d48a35
Author: Nuno S=C3=A1 <[email protected]>

dmaengine: stm32-dma3: Use bus width capability helpers

This commit advertises the controller-wide bus width capabilities through t=
he
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 t=
he
error code.

Does this direct return bypass the clock cleanup?=20

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?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260730-dmaengine-=
[email protected]?part=3D5