[PATCH v2 0/2] gpio: rockchip: fix resource leaks and teardown bugs

[Bartosz Golaszewski]

On Wed, 27 May 2026 10:10:23 +0200, Bartosz Golaszewski <brgl at kernel.org> said:
> 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
>

Ah, nevermind my comment, I see patch 1/2 is a fix as well. I'll queue these
and fix the dev_err_probe() thing in tree.

Bart