From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: net: qrtr: Hold runtime PM during active data path operations
Date: Mon, 25 May 2026 19:03:04 +1000 [thread overview]
Message-ID: <review-patch4-20260522-mhi_runtimepm-v2-4-fbebf41a82bb@oss.qualcomm.com> (raw)
In-Reply-To: <20260522-mhi_runtimepm-v2-4-fbebf41a82bb@oss.qualcomm.com>
Patch Review
**Issue 1 - devm_kmalloc for RX buffers:**
This isn't introduced by this patch, but the PM changes interact with it: `qcom_mhi_qrtr_queue_dl_buffers` uses `devm_kmalloc` for DL buffers. These persist for the lifetime of the device and are never freed on the error path within this function. The PM wrapping is correct, but the underlying memory management concern remains.
**Issue 2 - PM in DL callback:**
```c
+ rc = pm_runtime_get(&qdev->mhi_dev->dev);
+ if (rc < 0 && rc != -EINPROGRESS) {
+ dev_err(&mhi_dev->dev, "pm_runtime_get failed %d\n", rc);
+ pm_runtime_put_noidle(&qdev->mhi_dev->dev);
+ return;
+ }
+
/* Done with the buffer, now recycle it for future use */
rc = mhi_queue_buf(mhi_dev, DMA_FROM_DEVICE, ...);
```
The DL callback fires because data was received - meaning the device was necessarily active to deliver the interrupt/data. Taking a PM reference here to requeue the buffer is correct, but returning without requeuing the buffer on PM failure means that buffer is permanently lost from the RX ring. This will eventually starve the RX path. A better approach might be to attempt the requeue regardless (since the device clearly is active if the callback is running).
**Issue 3 - Same probe/remove asymmetry as patch 3.**
---
Generated by Claude Code Patch Reviewer
next prev parent reply other threads:[~2026-05-25 9:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-22 10:00 [PATCH v2 0/6] bus: mhi: Fix broken runtime PM design Krishna Chaitanya Chundru
2026-05-22 10:00 ` [PATCH v2 1/6] bus: mhi: Replace controller runtime_get/put callbacks with direct PM runtime APIs Krishna Chaitanya Chundru
2026-05-25 9:03 ` Claude review: " Claude Code Review Bot
2026-05-22 10:00 ` [PATCH v2 2/6] bus: mhi: Drop controller runtime PM callback indirection Krishna Chaitanya Chundru
2026-05-25 9:03 ` Claude review: " Claude Code Review Bot
2026-05-22 10:00 ` [PATCH v2 3/6] net: mhi_net: Hold runtime PM during active data path operations Krishna Chaitanya Chundru
2026-05-22 20:09 ` Loic Poulain
2026-05-25 9:03 ` Claude review: " Claude Code Review Bot
2026-05-22 10:00 ` [PATCH v2 4/6] net: qrtr: " Krishna Chaitanya Chundru
2026-05-25 9:03 ` Claude Code Review Bot [this message]
2026-05-22 10:00 ` [PATCH v2 5/6] net: wwan: " Krishna Chaitanya Chundru
2026-05-25 9:03 ` Claude review: " Claude Code Review Bot
2026-05-22 10:00 ` [PATCH v2 6/6] bus: mhi: host: Fix runtime PM ownership between clients and controller Krishna Chaitanya Chundru
2026-05-25 9:03 ` Claude review: " Claude Code Review Bot
2026-05-25 9:03 ` Claude review: bus: mhi: Fix broken runtime PM design Claude Code Review Bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=review-patch4-20260522-mhi_runtimepm-v2-4-fbebf41a82bb@oss.qualcomm.com \
--to=claude-review@example.com \
--cc=dri-devel-reviews@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox