Thread (10 messages) 10 messages, 4 authors, 2026-05-30

Re: [PATCH v2 3/6] net: mhi_net: Hold runtime PM during active data path operations

From: Paolo Abeni <pabeni@redhat.com>
Date: 2026-05-26 11:34:55
Also in: ath11k, ath12k, dri-devel, linux-arm-msm, linux-wireless, lkml

On 5/22/26 10:09 PM, Loic Poulain wrote:
On Fri, May 22, 2026 at 12:01 PM Krishna Chaitanya Chundru
[off-list ref] wrote:
quoted
The mhi_net driver does not coordinate with runtime PM, which allows the
underlying MHI controller to be runtime-suspended while transmit, receive,
or RX buffer refill operations are in progress. This can lead to stalled
transfers or failed queueing once runtime PM is enabled in the MHI core.

Add runtime PM reference counting to the mhi_net data path to keep the
controller active for the duration of TX, RX, and buffer management
operations. Enable runtime PM during probe and take/release references
explicitly around these critical paths.

Signed-off-by: Krishna Chaitanya Chundru <redacted>
---
 drivers/net/mhi_net.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
diff --git a/drivers/net/mhi_net.c b/drivers/net/mhi_net.c
index ae169929a9d8..5d7f9ccdb17b 100644
--- a/drivers/net/mhi_net.c
+++ b/drivers/net/mhi_net.c
@@ -9,6 +9,7 @@
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
 #include <linux/netdevice.h>
+#include <linux/pm_runtime.h>
 #include <linux/skbuff.h>
 #include <linux/u64_stats_sync.h>
@@ -76,11 +77,19 @@ static netdev_tx_t mhi_ndo_xmit(struct sk_buff *skb, struct net_device *ndev)
        struct mhi_device *mdev = mhi_netdev->mdev;
        int err;

+       err = pm_runtime_get(&mdev->dev);
+       if (err < 0 && err != -EINPROGRESS) {
+               dev_err(&mdev->dev, "pm_runtime_get failed %d\n", err);
+               pm_runtime_put_noidle(&mdev->dev);
+               goto exit_drop;
+       }
+
I am wondering what the value is in pushing this PM responsibility to
each individual MHI client driver and requiring every MHI operation to
be bracketed with runtime PM handling.

What does the client driver know here that the MHI core itself cannot
handle centrally? It feels like ensuring the controller is
runtime-active during transfer could be handled generically in the
framework instead of duplicating the same logic in every client.
Indeed if *feel* like the MHI core should be able to put together all
the status needed to correctly track the PM.

Adding PM tracking to the NIC driver network data-path looks quite bad.

/P
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help