summaryrefslogtreecommitdiff
path: root/usr
diff options
context:
space:
mode:
authorDanilo Krummrich <dakr@kernel.org>2026-01-27 21:17:12 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2026-02-16 10:17:50 +0100
commit1c04c3a4de8d4bcb9202f94c44f26c57c2572308 (patch)
tree0e1697d89706fad6daea1e1963094e2b5924dcc8 /usr
parent455e882192c9833f176f3fbbbb2f036b6c5bf555 (diff)
downloadlinux-1c04c3a4de8d4bcb9202f94c44f26c57c2572308.tar.gz
linux-1c04c3a4de8d4bcb9202f94c44f26c57c2572308.tar.bz2
linux-1c04c3a4de8d4bcb9202f94c44f26c57c2572308.zip
gpio: omap: do not register driver in probe()
commit 730e5ebff40c852e3ea57b71bf02a4b89c69435f upstream. 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") Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260127201725.35883-1-dakr@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'usr')
0 files changed, 0 insertions, 0 deletions