public inbox for linux-gpio@vger.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: gregkh@linuxfoundation.org, rafael@kernel.org,
	broonie@kernel.org, will@kernel.org, grygorii.strashko@ti.com,
	ssantosh@kernel.org, khilman@kernel.org, linusw@kernel.org,
	brgl@kernel.org
Cc: driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-omap@vger.kernel.org, linux-gpio@vger.kernel.org,
	Danilo Krummrich <dakr@kernel.org>
Subject: [PATCH] gpio: omap: do not register driver in probe()
Date: Fri, 23 Jan 2026 14:31:56 +0100	[thread overview]
Message-ID: <20260123133614.72586-1-dakr@kernel.org> (raw)

Commit 11a78b794496 ("ARM: OMAP: MPUIO wake updates") registers the
omap_mpuio_driver from omap_mpuio_init(), which is called from
omap_gpio_probe().

However, it neither makes sense to register drivers from probe()
callbacks of other drivers, nor does the driver core allow registering
drivers with a device lock already being held.

The latter was revealed by commit dc23806a7c47 ("driver core: enforce
device_lock for driver_match_device()") leading to a potential deadlock
condition described in [1].

Additionally, the omap_mpuio_driver is never unregistered from the
driver core, even if the module is unloaded.

Hence, register the omap_mpuio_driver from the module initcall and
unregister it in module_exit().

Link: https://lore.kernel.org/lkml/DFU7CEPUSG9A.1KKGVW4HIPMSH@kernel.org/ [1]
Fixes: dc23806a7c47 ("driver core: enforce device_lock for driver_match_device()")
Fixes: 11a78b794496 ("ARM: OMAP: MPUIO wake updates")
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
---
In addition to this fix, the omap_mpuio_device (struct platform_device) should
not be declared as global static, especially when their backing memory can
become invalue due to the module being unloaded. Devices are reference counted
and should be allocated dynamically. This needs a separate fix.

Besides that, the whole construct seems a bit questionable and I'm not exactly
sure what should be achieved by registering the *same* static device everytime
probe() is called for the omap_gpio_driver.

However, for the purpose of avoiding the described potential deadlock in
combination with commit dc23806a7c47 ("driver core: enforce device_lock for
driver_match_device()"), this patch only addresses the driver registration
issue.
---
 drivers/gpio/gpio-omap.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index e136e81794df..8db71a2db9ff 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -800,9 +800,7 @@ static struct platform_device omap_mpuio_device = {
 static inline void omap_mpuio_init(struct gpio_bank *bank)
 {
 	platform_set_drvdata(&omap_mpuio_device, bank);
-
-	if (platform_driver_register(&omap_mpuio_driver) == 0)
-		(void) platform_device_register(&omap_mpuio_device);
+	(void)platform_device_register(&omap_mpuio_device);
 }
 
 /*---------------------------------------------------------------------*/
@@ -1575,13 +1573,24 @@ static struct platform_driver omap_gpio_driver = {
  */
 static int __init omap_gpio_drv_reg(void)
 {
-	return platform_driver_register(&omap_gpio_driver);
+	int ret;
+
+	ret = platform_driver_register(&omap_mpuio_driver);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&omap_gpio_driver);
+	if (ret)
+		platform_driver_unregister(&omap_mpuio_driver);
+
+	return ret;
 }
 postcore_initcall(omap_gpio_drv_reg);
 
 static void __exit omap_gpio_exit(void)
 {
 	platform_driver_unregister(&omap_gpio_driver);
+	platform_driver_unregister(&omap_mpuio_driver);
 }
 module_exit(omap_gpio_exit);
 

base-commit: ed1ac3c977dd6b119405fa36dd41f7151bd5b4de
-- 
2.52.0


             reply	other threads:[~2026-01-23 13:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-23 13:31 Danilo Krummrich [this message]
2026-01-23 13:44 ` [PATCH] gpio: omap: do not register driver in probe() Danilo Krummrich
2026-01-26  9:06   ` Bartosz Golaszewski
2026-01-26 11:35     ` Danilo Krummrich
2026-01-23 13:57 ` Danilo Krummrich
2026-01-23 14:19   ` Greg KH
2026-01-23 14:25     ` Danilo Krummrich
2026-01-23 15:23       ` Greg KH
2026-01-23 15:48         ` Danilo Krummrich
2026-01-27  9:09 ` Bartosz Golaszewski
2026-01-27 13:37   ` Danilo Krummrich
2026-01-27 19:26     ` 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=20260123133614.72586-1-dakr@kernel.org \
    --to=dakr@kernel.org \
    --cc=brgl@kernel.org \
    --cc=broonie@kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=grygorii.strashko@ti.com \
    --cc=khilman@kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=ssantosh@kernel.org \
    --cc=will@kernel.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