Claude review: clk: Add __clk_disable_unprepare_counts_only() helper

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**pm_runtime leak/hazard in unprepare path:**
The patch gates `core->ops->unprepare` with the new `call_unprepare_op` flag, but `clk_pm_runtime_put(core)` at the end of `clk_core_unprepare()` is still called unconditionally:

```c
	if (call_unprepare_op && core->ops->unprepare)
		core->ops->unprepare(core->hw);

	trace_clk_unprepare_complete(core);
	clk_core_unprepare(core->parent, call_unprepare_op);
	clk_pm_runtime_put(core);   // <-- still called in counts-only mode
```

When `clk_core_prepare()` was called by simpledrm, it called `clk_pm_runtime_get()` (line 1110 of clk.c in drm-next). The matching `clk_pm_runtime_put()` calls `pm_runtime_put_sync()`, which can trigger the clock controller device's `runtime_suspend` callback. If simpledrm held the only prepare reference on clocks from a given controller, this could power down the controller's power domain — exactly the kind of hardware disturbance the series is trying to avoid.

This should either be gated the same way as the ops callback, or the rationale for why it's safe should be documented.

**Misleading tracepoints:**
`trace_clk_unprepare` / `trace_clk_unprepare_complete` and `trace_clk_disable` / `trace_clk_disable_complete` fire regardless of the `call_*_op` flag. When no actual disable/unprepare happens, these trace events are misleading and could confuse ftrace-based debugging. Consider gating them with the same boolean, or adding distinct trace events for counts-only operations.

**WARN for CLK_IS_CRITICAL:**
In the counts-only path, the WARN for decrementing a critical clock's last reference still fires:

```c
	if (WARN(core->enable_count == 1 && core->flags & CLK_IS_CRITICAL,
	    "Disabling critical %s\n", core->name))
		return;
```

While CLK_IS_CRITICAL clocks shouldn't appear in simple-framebuffer DT nodes, the semantic is arguably wrong: we're not "disabling" the clock, we're releasing a count. This is a minor concern but could be confusing if it triggers.

**API naming and export:**
The function is `EXPORT_SYMBOL_GPL` and the `__` prefix clearly signals "internal/unusual." The kerneldoc is good. Consider whether a `clk_release_counts()` or `clk_detach_counts()` name would be clearer, since the function doesn't disable or unprepare anything.

**Overall correctness of the bool-parameter approach:**
Adding `bool call_unprepare_op` / `bool call_disable_op` to internal functions is a reasonable pattern (the cover letter correctly notes that duplicating the logic is worse). The changes to all existing callers to pass `true` are mechanically correct — I verified each call site:
- `clk_core_unprepare_lock()` — passes `true` ✓
- `clk_core_prepare()` error path — passes `true` ✓  
- `clk_change_rate()` — passes `true` ✓
- `__clk_core_init()` — passes `true` ✓
- `clk_core_disable_lock()` — passes `true` ✓
- `clk_core_enable()` error path — passes `true` ✓

---
Generated by Claude Code Patch Reviewer