From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/msm/a6xx: Append SEL regs to dyn pwrup reglist Date: Sat, 16 May 2026 10:50:11 +1000 Message-ID: In-Reply-To: <20260514134052.361771-16-robin.clark@oss.qualcomm.com> References: <20260514134052.361771-1-robin.clark@oss.qualcomm.com> <20260514134052.361771-16-robin.clark@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 key patch for IFPC support - it appends SEL register values to the dynamic pwrup reglist so they're restored on IFPC exit. **`cpu_gpu_lock::regs[62]` -> `regs[]` flex array change.** This is a structural change to a shared-memory structure between CPU and GPU firmware (SQE). The `regs[62]` was presumably sized to fit within a page with the header. Changing to flex array is fine for the C side since the allocation is already `PAGE_SIZE` (now `2 * PAGE_SIZE`), but the firmware side needs to agree on the maximum size. The doubling of `pwrup_reglist` allocation in patch 14 provides the space. This should be safe as long as SQE reads `dynamic_list_len` to determine how many entries to process (which it does). **Memory barrier usage is correct.** The code properly uses `wmb()` between writing the SEL entries and updating `dynamic_list_len`, and separately between clearing `dynamic_list_len` and writing new entries. The comment about the race with SQE on IFPC exit is well-reasoned. **Issue: No bounds checking on reglist writes.** The `perfcntr_select()` function writes to `*reglist` without checking that it stays within the `2 * PAGE_SIZE` allocation. In practice, the number of counters should be well within bounds, but a defensive check would be prudent. The comment in patch 14 mentions ~190 counters on gen8 with the old PAGE_SIZE. With 2 pages (8192 bytes minus header), and each entry being 3 * 4 = 12 bytes, that's ~680 entries, which should be more than enough. But a `WARN_ON_ONCE` if approaching the limit would be useful. --- Generated by Claude Code Patch Reviewer