From nobody Sat Feb 7 21:15:58 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFE4D38DD3; Fri, 23 Jan 2026 13:36:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769175391; cv=none; b=C6xIX/SKH/unxmu8IvU8lCOs0A7kKEuZQlWd1FCMM26zT1+Sod7CoiuqvDk7Jea8O+5KdmLNBYvFLXI10IsANclreL/RW23ukCCNg5Q9LK2CprkhirkWe5wjF/ZtHPWbBqKZ4A7wdsPMxCt6wgXuPPvt1JuQimO/Ik1Fx85cTFc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769175391; c=relaxed/simple; bh=uhsda+CucBOaR/Zt91EPvftxu2dEouhHw7HKe7tHy3w=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Vi3EvjEdoJW+Xw53P4DUd++0RZR8JmX5+2gSwx9NkJmOZ21CDZv/1g+d3AIXdS15zuFBTdVC4eP5BJwP6Df3x8KeZ7ogCkmtIKIN2yjwujD2r8CKEYceNoyJq1czxoGWf537aI+6TE/y+R/Atqd8xYmADmExAwdirvej/pKFkRk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=u0iv38m3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="u0iv38m3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B29DFC4CEF1; Fri, 23 Jan 2026 13:36:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769175391; bh=uhsda+CucBOaR/Zt91EPvftxu2dEouhHw7HKe7tHy3w=; h=From:To:Cc:Subject:Date:From; b=u0iv38m3kFUKEwKyI28S8Nku3NfDBEhXUPyBRS83+HWfZNY4cBQHARiqlk0VjzUWW oncQFosuvvhbe6Upp2gclgr5bi+W/RkBCnFuO9YNjJmcxI8CSTxJ9fciM6hN7ZPo+r sLQ0CPjHRDSiv5hbZVLImE38gqq0KpYEsSxuAMSqISDwMbeqgsasVNaVQ4pXFfiGkz Qv9JOUv1xRF86Rw0koEEDwy307+c5dH/iiDsAyLHWjaoT3jfqeWXsbezlREb81fCgE vgg2x/TcTKcTcRgCOyqxszsNH+iC21cw2blSza4dGwxKYOMid0F3c2o7/cUt/Djopo 5Dyc+z21Uqh0g== From: Danilo Krummrich 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 Subject: [PATCH] gpio: omap: do not register driver in probe() Date: Fri, 23 Jan 2026 14:31:56 +0100 Message-ID: <20260123133614.72586-1-dakr@kernel.org> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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_dev= ice()") Fixes: 11a78b794496 ("ARM: OMAP: MPUIO wake updates") Signed-off-by: Danilo Krummrich Reviewed-by: Greg Kroah-Hartman --- In addition to this fix, the omap_mpuio_device (struct platform_device) sho= uld not be declared as global static, especially when their backing memory can become invalue due to the module being unloaded. Devices are reference coun= ted and should be allocated dynamically. This needs a separate fix. Besides that, the whole construct seems a bit questionable and I'm not exac= tly sure what should be achieved by registering the *same* static device everyt= ime 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 =3D { static inline void omap_mpuio_init(struct gpio_bank *bank) { platform_set_drvdata(&omap_mpuio_device, bank); - - if (platform_driver_register(&omap_mpuio_driver) =3D=3D 0) - (void) platform_device_register(&omap_mpuio_device); + (void)platform_device_register(&omap_mpuio_device); } =20 /*---------------------------------------------------------------------*/ @@ -1575,13 +1573,24 @@ static struct platform_driver omap_gpio_driver =3D { */ static int __init omap_gpio_drv_reg(void) { - return platform_driver_register(&omap_gpio_driver); + int ret; + + ret =3D platform_driver_register(&omap_mpuio_driver); + if (ret) + return ret; + + ret =3D platform_driver_register(&omap_gpio_driver); + if (ret) + platform_driver_unregister(&omap_mpuio_driver); + + return ret; } postcore_initcall(omap_gpio_drv_reg); =20 static void __exit omap_gpio_exit(void) { platform_driver_unregister(&omap_gpio_driver); + platform_driver_unregister(&omap_mpuio_driver); } module_exit(omap_gpio_exit); =20 base-commit: ed1ac3c977dd6b119405fa36dd41f7151bd5b4de --=20 2.52.0