Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Scardovi <scardracs@disroot.org>
To: brgl@kernel.org
Cc: heiko@sntech.de, linusw@kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
	scardracs@disroot.org
Subject: [PATCH v2 0/2] gpio: rockchip: fix resource leaks and teardown bugs
Date: Tue, 26 May 2026 19:02:44 +0200	[thread overview]
Message-ID: <20260526171050.12785-1-scardracs@disroot.org> (raw)
In-Reply-To: <CAMRc=Mfk9tP091DN=5kjb8fvFhj1=MiBZSq4NJ7+k5LNCVy9bw@mail.gmail.com>

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.

Changes in v2:

- Rephrased patch 1 and patch 2 commit messages to use the imperative as
  requested.

- Clarified in the commit message of patch 2 why devm_clk_get() cannot
  be used for the debounce clocks.

The patches included in this series:

1. Convert the main clock (bank->clk) to use devm_clk_get_enabled(),
   simplifying the code and fixing an existing clk_put() leak.

2. Fix several teardown bugs and resource leaks:
   - Fix a reference leak for the debounce clock (bank->db_clk)
     by properly releasing it with a devm action.
   - Fix a potential kernel panic on module unload by unregistering the
     chained IRQ handler (rockchip_irq_demux) in the remove() callback.
   - Fix an IRQ domain and generic chip memory leak by calling
     irq_domain_remove() during module unload.


Marco Scardovi (2):
  gpio: rockchip: convert bank->clk to devm_clk_get_enabled()
  gpio: rockchip: teardown bugs and resource leaks

 drivers/gpio/gpio-rockchip.c | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

-- 
2.54.0



  reply	other threads:[~2026-05-26 17:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-25 16:39 [PATCH 0/2] gpio: rockchip: fix resource leaks and teardown bugs Marco Scardovi (scardracs)
2026-05-25 16:39 ` [PATCH 1/2] gpio: rockchip: convert bank->clk to devm_clk_get_enabled() Marco Scardovi (scardracs)
2026-05-25 16:39 ` [PATCH 2/2] gpio: rockchip: fix teardown bugs and resource leaks Marco Scardovi (scardracs)
2026-05-26 10:53   ` Bartosz Golaszewski
2026-05-26 17:02     ` Marco Scardovi [this message]
2026-05-26 17:02       ` [PATCH v2 1/2] gpio: rockchip: convert bank->clk to devm_clk_get_enabled() Marco Scardovi
2026-05-26 17:02       ` [PATCH v2 2/2] gpio: rockchip: teardown bugs and resource leaks Marco Scardovi
2026-05-27  8:11         ` Bartosz Golaszewski
2026-05-27  8:10       ` [PATCH v2 0/2] gpio: rockchip: fix resource leaks and teardown bugs Bartosz Golaszewski
2026-05-27  8:12         ` Bartosz Golaszewski
2026-05-27  8:17       ` Bartosz Golaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260526171050.12785-1-scardracs@disroot.org \
    --to=scardracs@disroot.org \
    --cc=brgl@kernel.org \
    --cc=heiko@sntech.de \
    --cc=linusw@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox