[PATCH v2 0/2] gpio: rockchip: fix resource leaks and teardown bugs
Bartosz Golaszewski
brgl at kernel.org
Wed May 27 01:10:23 PDT 2026
On Tue, 26 May 2026 19:02:44 +0200, Marco Scardovi <scardracs at disroot.org> said:
> Hi Bartosz,
> thank you for the review on the first version of this series.
>
> TL;DR: There's no clock-names property in the DTBs for the GPIO banks,
> and they don't expose a separate debounce clock in hardware.
>
> Regarding your question: existing DTBs currently do not provide clock-names
> for these GPIO nodes and instead rely on positional clock ordering.
>
> While we could extend the binding to optionally support clock-names going
> forward, the driver still needs to remain compatible with existing DTBs, so
> it cannot rely on name-based lookup here.
>
> For this reason, keeping the index-based of_clk_get(..., 1) lookup together
> with devm_add_action_or_reset() for cleanup seemed like the safest option.
>
> A good example can be gpio1 in rk3399-base.dtsi, where the clocks property
> is defined as:
>
> clocks = <&pmucru PCLK_GPIO1_PMU>;
>
> If we switched to name-based lookup via devm_clk_get(dev, "db"), it would
> fail for existing DTBs because they do not define the corresponding
> clock-names property.
>
> Additionally, PMU banks such as gpio1 do not expose a separate debounce
> clock in hardware, so there would not be a matching entry anyway.
>
> Therefore, using of_clk_get(..., 1) is currently the only approach that
> preserves compatibility with existing DTBs while avoiding regressions.
>
I see. Can you please reverse the order of the patches? The fix should go into
v7.1 and stable branches, patch 1/2 is a new feature so it'll go into v7.2.
Bart
More information about the Linux-rockchip
mailing list