From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: bus: mhi: host: Fix runtime PM ownership between clients and controller
Date: Mon, 25 May 2026 19:03:05 +1000
Message-ID: <review-patch6-20260522-mhi_runtimepm-v2-6-fbebf41a82bb@oss.qualcomm.com>
In-Reply-To: <20260522-mhi_runtimepm-v2-6-fbebf41a82bb@oss.qualcomm.com>
References: <20260522-mhi_runtimepm-v2-0-fbebf41a82bb@oss.qualcomm.com> <20260522-mhi_runtimepm-v2-6-fbebf41a82bb@oss.qualcomm.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Patch Review

This is the most complex patch and has the most concerning issues.

**Issue 1 (Bug) - dev_wake counter imbalance:**

`__mhi_device_get_sync` is modified to call `mhi_device_put` on error:

```c
 	if (!ret || MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state)) {
-		read_lock_bh(&mhi_cntrl->pm_lock);
-		mhi_cntrl->wake_put(mhi_cntrl, false);
-		read_unlock_bh(&mhi_cntrl->pm_lock);
+		mhi_device_put(mhi_cntrl->mhi_dev);
 		return -EIO;
 	}
```

But `mhi_device_put` does `mhi_dev->dev_wake--` before calling `wake_put`. The matching increment `mhi_dev->dev_wake++` only exists in the **exported** `mhi_device_get_sync()`, not in the **internal** `__mhi_device_get_sync()`. When `__mhi_device_get_sync` is called directly (as in `mhi_pm_mission_mode_transition`), there's no `dev_wake++`, so calling `mhi_device_put` in the error path will decrement `dev_wake` below its original value, corrupting the counter.

Similarly, in `mhi_pm_mission_mode_transition`:

```c
 error_mission_mode:
-	mhi_cntrl->wake_put(mhi_cntrl, false);
-	read_unlock_bh(&mhi_cntrl->pm_lock);
+	mhi_device_put(mhi_cntrl->mhi_dev);
```

This calls `mhi_device_put` to undo `__mhi_device_get_sync`, but again, `dev_wake--` in `mhi_device_put` has no matching `dev_wake++`.

**Fix suggestion:** Either create a new internal cleanup helper that does `wake_put + pm_runtime_put` without the `dev_wake--`, or explicitly do the `dev_wake++` in `__mhi_device_get_sync` to match.

**Issue 2 - Race window in __mhi_device_get_sync:**

```c
+	read_unlock_bh(&mhi_cntrl->pm_lock);
+
+	pm_runtime_get_sync(&mhi_cntrl->mhi_dev->dev);
+	read_lock_bh(&mhi_cntrl->pm_lock);
 	mhi_cntrl->wake_get(mhi_cntrl, true);
```

Between dropping the lock and reacquiring it after `pm_runtime_get_sync`, the PM state could transition to an error state. The code doesn't re-check for error state after reacquiring the lock before calling `wake_get`. If the device entered an error state during `pm_runtime_get_sync`, calling `wake_get` on a dead device could be problematic.

**Issue 3 - Lost wakeup event in mhi_device_put:**

The original `mhi_device_put` checked for suspend state and called `mhi_trigger_resume`, which includes `pm_wakeup_event`:

```c
-	if (MHI_PM_IN_SUSPEND_STATE(mhi_cntrl->pm_state))
-		mhi_trigger_resume(mhi_cntrl);
```

This `pm_wakeup_event` path is now removed entirely. The assumption is that `pm_runtime_put` is sufficient, but `pm_wakeup_event` serves a different purpose (keeping the system awake, not just the device). If there are system suspend paths that depend on this wakeup event, removing it silently could cause regressions.

**Issue 4 - devm_pm_runtime_set_active_enabled return value ignored:**

```c
+	pm_runtime_no_callbacks(&mhi_cntrl->mhi_dev->dev);
+	devm_pm_runtime_set_active_enabled(&mhi_cntrl->mhi_dev->dev);
```

The return value of `devm_pm_runtime_set_active_enabled` is not checked. This function can fail (e.g., if `pm_runtime_set_active` or `devm_add_action_or_reset` fails). Compare with the client driver patches (3-5) which all check the return value. This should be checked and propagated.

---
Generated by Claude Code Patch Reviewer