From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 863253DE44A for ; Tue, 26 May 2026 11:34:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779795295; cv=none; b=XhqIDoZqkb27IH20TSxVb6D9gPls/awKCrL4cV9m5HJUpqcjEnhl4Ohu3rhS0yCj8Hv4qxrN2LCNDGs9Mj5qxZyq4ueOf9arQvojhbC8Y/qkmI8IHs8TWaIpf1PpQM4XCvZUsPGJNtgo+y80IXG51ifLUjPs8VWpxkPwExePq2Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779795295; c=relaxed/simple; bh=ocxFYI38hxzb1ERZvNMOfcjBpfFa+PxSGRxdLDGrzLA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=iegLnLga0OtqECXzxjJidnUVWOV9YzoG372FPlwbm1wYD+YpwMwnVQ7xblc1NzfIjCPXg3vEJVC88v4E+1tFYcXRFp+cesWQkk+Xdg24DKjl4K4CK2im5vzsnlyPgriR0wK6MDb8Tv0en3OeixhJc97ce6OoaQ+zreD9CJpZlrg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=DdKpm/Ue; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=lLsrogCl; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="DdKpm/Ue"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="lLsrogCl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779795292; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VD+dmiG81dGo1mjueRmNr772xEYjIurIakGJoB8fU4s=; b=DdKpm/UezA3KpMPxgHlp1Sn9g6Plmp6vyALmeK7Ri6QRFhbU6voF0bN43I6wZnMVl7Ao7l ZpWSCSzFCljR+2N6Y82uwT3cy92SxTEqAS3yrwGihdb10KjsdLlM4TOMJxraQSYviRiAX7 1ENHpaEmYJD2guIP3GbZo1J4JdEbI0s= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-410-okt0XjIxNKmpHoH7LN1cpQ-1; Tue, 26 May 2026 07:34:51 -0400 X-MC-Unique: okt0XjIxNKmpHoH7LN1cpQ-1 X-Mimecast-MFC-AGG-ID: okt0XjIxNKmpHoH7LN1cpQ_1779795290 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-490479c2911so44522985e9.2 for ; Tue, 26 May 2026 04:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1779795290; x=1780400090; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=VD+dmiG81dGo1mjueRmNr772xEYjIurIakGJoB8fU4s=; b=lLsrogClLM4GZ9192J/4nag4e0VHHJQ7rl0V/h0SeR4fXVJApe2BnI5Zki2CxRcnCD tT/SjPJYbcomd1SYtZnJb+ETKBKX6H8ogN3x7pQ3bCkCvh51ZCtPMV8+W5mlb0qa/64K +yZWgxsmtunNRxqHAr457Kn8d1jqatdg4xrSDrKaP+vQAhOKtpzdVGLzKnatA6kt31xt LV5XpdkRci1fqzwXZg4sUuNrOsrtZUiyRxUNekdx3SYZayQ6paadKc4DzMIClMfuoh35 JCN4yh5oK0++j3ci8nA8QGHzCpeX9/CG3axD4yYrmjVBkC44crh/59f8qgg0Q1rOhbpL 043g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779795290; x=1780400090; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VD+dmiG81dGo1mjueRmNr772xEYjIurIakGJoB8fU4s=; b=NzEaA1GzFNWfxHhKSp5wDWhS9qYc46z4L4vvIyLg+bxzlpmzAT/hhPerO8d0C7EQOX 0+FXFu7jGT6XcU3r37cLLB69XKAAkujtNEgSHoKvxlOBfdy1pBBFeH25vebKalrsld9m 3yv1CgOrB2e0hXZ8iH3bhpxPcfL+WZJ56yCByLICdT6CRZEsKhPIcFTylqr0sVWvt0TW qd7MIsQqJNt8nUsVXZ4kFV9PakeAf9ETOCdYKh+VXXThINTNPW32P9nr4ptK6aTZGbYK TsdUYbcAiv7jve1dhL7dxYhYXQZgbS26KyubzYBxpwSr/bBJtHlJUu4ndRrg6gyOp7Qe ryWg== X-Forwarded-Encrypted: i=1; AFNElJ8pxqwzy6vp4CcqT5Rjr40iD/oIKCkwxweV27wv4rE+ccbX6D7L2A9nIJymS7MgszHYAPweB10AfPQtwDg=@vger.kernel.org X-Gm-Message-State: AOJu0YxNuEsFgqX24kbzUBsiZvNYvN5vrDagI4RlpfdiclUUe8k+nkNN IQ6Fe/+g9d5jZ5DjcYvMjSCSGtFiSa9nQr7BVM2CL508TTG3zi8W6QM9Y8XbYz8Zx7g/IvdEvK0 taS/+Tce1kIkRIdnJ7t9ksJHfFhTzLNjPZk2mhGGRKON5dX/vCFPgyhBzBLN4HjoCpw== X-Gm-Gg: Acq92OHyrnno/S/kt4hmxFb6MkD2knUGUi2aaF0ZQwaWbLRnAgRNU9P5jE1zk6sz3PE PoMv3HimAhX5qAvwk3KfoZzEsa9tYivApexhWkCkCs+IUVVaojyGKSoPEfGmdn1PfACyaYp2Lkt +B8xIVp3m8v31J5zDDwrhIMKN4MWoACKd6iG/cqB++LCa6kqRs6SvuRrSM5gtUgoU3hDj1T9eR7 PH1FouxUVXhUvAodv8EEjvj1oJDTln43r5YKLM1g3sqfN/0McCqR1NFTbJJwmByNp1Y1gM07FiO Bch3Ds1YiXLgBsDvEi5h1Ne+GQjGUWhHzwolge6KJqfIVsy86p7tO5/6HfmiZxIkGmeQkTeDGPY 4ygPr6mKqR24q5ipvgDezYhp9UhvuNv10NzthEkSD93hiKQSS+M+Dhwe+Yg== X-Received: by 2002:a05:600c:4ecc:b0:48a:56de:d62a with SMTP id 5b1f17b1804b1-490424b3c7fmr275107485e9.11.1779795289587; Tue, 26 May 2026 04:34:49 -0700 (PDT) X-Received: by 2002:a05:600c:4ecc:b0:48a:56de:d62a with SMTP id 5b1f17b1804b1-490424b3c7fmr275106815e9.11.1779795289064; Tue, 26 May 2026 04:34:49 -0700 (PDT) Received: from [192.168.88.32] ([212.105.155.152]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4904526c926sm565711385e9.1.2026.05.26.04.34.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2026 04:34:48 -0700 (PDT) Message-ID: <5a54d307-0b8c-468d-9183-6433f9daba56@redhat.com> Date: Tue, 26 May 2026 13:34:46 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/6] net: mhi_net: Hold runtime PM during active data path operations To: Loic Poulain , Krishna Chaitanya Chundru Cc: Manivannan Sadhasivam , Jeff Hugo , Carl Vanderlip , Oded Gabbay , Jeff Johnson , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , Sergey Ryazanov , Johannes Berg , mhi@lists.linux.dev, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-wireless@vger.kernel.org, ath11k@lists.infradead.org, ath12k@lists.infradead.org, netdev@vger.kernel.org, mayank.rana@oss.qualcomm.com, quic_vbadigan@quicinc.com, vivek.pernamitta@oss.qualcomm.com References: <20260522-mhi_runtimepm-v2-0-fbebf41a82bb@oss.qualcomm.com> <20260522-mhi_runtimepm-v2-3-fbebf41a82bb@oss.qualcomm.com> From: Paolo Abeni Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 5/22/26 10:09 PM, Loic Poulain wrote: > On Fri, May 22, 2026 at 12:01 PM Krishna Chaitanya Chundru > wrote: >> >> 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 >> --- >> 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 >> #include >> #include >> +#include >> #include >> #include >> >> @@ -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