[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230511073428.10264-1-u.kleine-koenig@pengutronix.de>
Date: Thu, 11 May 2023 09:34:28 +0200
From: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>
Cc: linux-kernel@...r.kernel.org, kernel@...gutronix.de
Subject: [PATCH] driver core: Call pm_runtime_put_sync() only after device_remove()
Many drivers that use runtime PM call pm_runtime_get_sync() or one of
its variants in their remove callback. So calling pm_runtime_put_sync()
directly before calling the remove callback results (under some
conditions) in the driver's suspend routine being called just to resume
it again afterwards.
So delay the pm_runtime_put_sync() call until after device_remove().
Confirmed on a stm32mp157a that doing
echo 4400e000.can > /sys/bus/platform/drivers/m_can_platform/unbind
(starting with a runtime-pm suspended 4400e000.can) results in one call
less of m_can_runtime_resume() and m_can_runtime_suspend() each after
this change was applied.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
---
Hello,
side note: To test I added a dev_info() to m_can_runtime_resume() and
m_can_runtime_suspend(). I was surprised that directly after boot I had:
# dmesg | grep -E '4400e000.can: m_can_runtime_(resume|suspend)' | wc -l
15
I didn't go down that rabbit hole to debug this.
Best regards
Uwe
drivers/base/dd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 9c09ca5c4ab6..d97f6b1486d1 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -1267,10 +1267,10 @@ static void __device_release_driver(struct device *dev, struct device *parent)
bus_notify(dev, BUS_NOTIFY_UNBIND_DRIVER);
- pm_runtime_put_sync(dev);
-
device_remove(dev);
+ pm_runtime_put_sync(dev);
+
if (dev->bus && dev->bus->dma_cleanup)
dev->bus->dma_cleanup(dev);
--
2.39.2
Powered by blists - more mailing lists