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/radeon: Add HAINAN clock adjustment Date: Wed, 11 Feb 2026 16:33:48 +1000 Message-ID: In-Reply-To: <20260210072524.15119-1-decce6@proton.me> References: <20260210072524.15119-1-decce6@proton.me> <20260210072524.15119-1-decce6@proton.me> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: Claude Code Patch Reviewer Patch Review **Subject line issues:** - Title is vague - should be more specific: "drm/radeon: Limit R5 M420 clocks to fix stability on HAINAN" **Commit message analysis:** ``` This patch limits the clock speeds of the AMD Radeon R5 M420 GPU from 850/1000MHz (core/memory) to 800/950 MHz, making it work stably. This patch is for radeon. ``` **Problems:** 1. States "This patch..." (redundant - commit messages should use imperative mood) 2. "This patch is for radeon" adds no value 3. Missing critical context: - What are the symptoms of instability? (artifacts, crashes, hangs?) - How was the issue reproduced and validated? - Why these specific frequency values? - Is this specific to certain board vendors or all R5 M420? - Has this been tested on multiple systems? **Better commit message would be:** ``` drm/radeon: Limit R5 M420 clocks to fix stability issues The AMD Radeon R5 M420 (HAINAN, device 0x666f revision 0x00) experiences [specific symptoms: crashes/artifacts/hangs] when running at default clock speeds of 850/1000 MHz (core/memory). Limit maximum clocks to 800/950 MHz to ensure stable operation. These values were determined through [testing methodology] and have been validated on [number] systems over [duration]. [If known: Link to bug report or add Closes: tag] ``` **Code review:** ```c + if ((rdev->pdev->device == 0x666f) && + (rdev->pdev->revision == 0x00)) { + max_sclk = 80000; + max_mclk = 95000; + } ``` **Issues:** 1. **Magic numbers**: The device ID `0x666f` should be defined as a constant with a meaningful name (though this matches existing code style in the file) 2. **Inconsistent units**: The comment in the commit message says "800/950 MHz" but the code uses `80000/95000` - these represent 10 kHz units, so: - 80000 * 10 kHz = 800 MHz (core) ✓ - 95000 * 10 kHz = 950 MHz (memory) ✓ The math is correct but could confuse reviewers 3. **Whitespace**: Uses `=09` (tab encoding in quoted-printable) - appears to match surrounding code style 4. **Location**: Correctly placed within the `CHIP_HAINAN` conditional block 5. **Logic**: The double-parentheses style `((condition))` matches the existing code pattern in this function 6. **Completeness**: Only checks revision 0x00 - are other revisions of this device ID affected? This needs clarification or testing data **Technical questions:** 1. Is device 0x666f revision 0x00 the only problematic variant? 2. Should this be configurable via module parameter for users who want to try higher clocks? 3. Has AMD provided any guidance on safe clock speeds for this part? 4. Could this be thermal-related rather than a silicon issue? 5. Should there be a pr_info() message when this workaround is applied? **Code correctness:** The code itself appears functionally correct and follows the existing pattern. **Testing validation needed:** - Multiple R5 M420 systems (different vendors/board designs) - Extended stress testing (hours/days) - Different workloads (3D, compute, video decode) - Temperature monitoring during testing **Recommendation:** **CHANGES REQUESTED** The functional change appears reasonable, but the patch needs: 1. Substantially improved commit message with proper justification 2. Testing details and validation data 3. Clarification on whether all R5 M420 GPUs need this or specific board variants 4. Consider adding a debug message when the limitation is applied 5. Confirmation that other revisions don't need similar treatment --- Generated by Claude Code Patch Reviewer