All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
To: Rosen Penev <rosenp@gmail.com>
Cc: linux-gpio@vger.kernel.org, Linus Walleij <linusw@kernel.org>,
	 Bartosz Golaszewski <brgl@kernel.org>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	 open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv2] gpio: mvebu: fix devres LIFO ordering between GPIO chip and IRQ domain
Date: Tue, 7 Jul 2026 09:13:09 +0200	[thread overview]
Message-ID: <akykuME0Y3eLOA2q@monoceros> (raw)
In-Reply-To: <20260706232223.774895-1-rosenp@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

On Mon, Jul 06, 2026 at 04:22:23PM -0700, Rosen Penev wrote:
> During driver removal, devres cleans up in LIFO order. The IRQ domain
> was created and its devm cleanup action registered after
> devm_gpiochip_add_data(), so the domain was destroyed before the GPIO
> chip was deregistered. If gpiod_to_irq() is called on a pin during
> this window, mvebu_gpio_to_irq() passes the freed mvchip->domain to
> irq_create_mapping().

Without having looked at your patch, I would expect that there is a
similar window during probe where calling gpiod_to_irq() between
devm_gpiochip_add_data() and IRQ domain creation results in an invalid
mvchip->domain being passed to irq_create_mapping(), right?

> Fix by moving the IRQ domain creation, devm cleanup action registration,
> generic chip allocation, and chip type setup before
> devm_gpiochip_add_data(). This ensures the GPIO chip is torn down
> first (preventing new IRQ mappings), then the IRQ domain is removed,
> and finally mvchip is freed.
> 
> Fixes: 644ee70267a9 ("gpio: mvebu: fix irq domain leak")

If the above is right, the referenced commit only creates the issue at
driver detach. The issue at probe time exists since 
fefe7b092345 ("gpio: introduce gpio-mvebu driver for Marvell SoCs")
which has `gpiochip_add(&mvchip->chip);` before coping for irqs.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2026-07-07  7:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06 23:22 [PATCHv2] gpio: mvebu: fix devres LIFO ordering between GPIO chip and IRQ domain Rosen Penev
2026-07-07  7:13 ` Uwe Kleine-König [this message]

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=akykuME0Y3eLOA2q@monoceros \
    --to=u.kleine-koenig@baylibre.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=brgl@kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rosenp@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.