Restore the CPU codename detection a merge resolution discarded

[manupawickramasinghe]

The margin this protects

SensorView's CPU table names six current parts that neither LibreHardwareMonitor nor upstream OpenHardwareMonitor identifies at all: Bartlett Lake, Clearwater Forest, Wildcat Lake, Panther Lake-R, Nova Lake and Diamond Rapids. LHM's IntelCpu.cs switches on only families 0x06 and 0x0F with a highest model of 0xCC, so Nova Lake (12h) and Diamond Rapids (13h) are structurally unreachable for it — the same family-only bug this table fixed.

That margin was silently deleted on master three commits ago. This PR restores it, corrects three CPU mislabels found while reviewing it, and makes the whole class of loss harder to repeat.

What happened

PR #30 replaced codename_for's family-only matching with real family+model tables. PR #31 rewrote the memory-type decoder in the same file, from a branch cut before #30 landed. The merge in 6b59f28 resolved that conflict by taking #31's side of sysinfo.rs wholesale — reverting #30 entirely:

• intel_codename and amd_codename — gone
• codename_for — back to 0x6 => "Intel Core", the exact bug ✨ Identify current CPUs instead of calling them all "Intel Core" #30 existed to fix
• all nine of its tests — deleted by the same resolution

Nothing caught it. Both PRs were green and the merge was clean. The regression is a deletion, so the file still looked healthy, and the tests that would have failed were removed alongside the code.

Status: on origin/master, but unreleased — v2.0.1 (2026-07-31) predates it. No hotfix urgency; this should land before the next tag.

Bugs found and fixed during review

The restored table had a defect of its own, in the same class it exists to prevent. Each of AMD families 17h, 19h and 1Ah ships a Threadripper at model 08h, right beside the server part at model 01h/02h. All three server arms were written as a 0x00..=0x0f range around one sourced model, swallowing all three Threadrippers:

CPUID	Real part	Reported as
17h/08	Colfax — TR 2990WX	"Summit Ridge/Naples (Zen)"
19h/08	Chagall — TR PRO 5995WX	"Milan (Zen 3)"
1Ah/08	Shimada Peak — TR PRO 9995WX	"Turin (Zen 5)"

Three desktop workstations each claiming to be a server part. The 17h case is worst: Pinnacle Ridge is Zen+, so a Ryzen 2700X (00800F82) got the wrong generation too.

recog_amd.c — already cited in these comments — names model 8 separately in all three families. Models it names individually are now matched individually; ranges are used only where AMD ships a block under one codename. While there, 17h gained Raven Ridge, Picasso, Rome, Renoir and Matisse; 19h gained Genoa and Storm Peak. Intel model 0x27 also moved from Bonnell to Saltwell, per intel-family.h (SALTWELL_MID 0x27; BONNELL 0x1C, BONNELL_MID 0x26).

Commits — read them in order

	Commit	Diff
1	Pin line endings	6 files, pure EOL churn
2	Restore the codename tables	225+/18− — the core change
3	Pin against upstream PR openhardwaremonitor#1671	tests only
4	Say 12h/13h, not 18h/19h	comment only
5	Stop three Threadrippers reporting EPYC	the mislabel fix + 5 tests

Commit 1 is line-ending noise and nothing else — git diff --ignore-cr-at-eol reports zero content change; review it with ?w=1. It comes first deliberately: five of the fifty-five Rust sources were CRLF, which made a 9-line change to firmware.rs render as 941 lines. That noise is precisely what let a 342-line deletion pass as clean. .gitattributes now pins *.rs to LF; the C# tree is marked -text and left byte-for-byte alone (verified: zero .cs files affected).

Commit 4 is small but worth a glance: the doc comment called Nova Lake family "18h" and Diamond Rapids "19h", because intel-family.h writes them in decimal (IFM(18, …), IFM(19, …)) and someone appended an h. 19h is AMD's Zen 3/Zen 4 family, named as such 30 lines above, so the two tables appeared to contradict each other.

On the upstream PRs

Upstream OHM PR openhardwaremonitor#1671 "New Intel Architectures" is the only open upstream PR that overlaps this code. It cannot be merged — it edits the C# tree, which CI never compiles; the shipping Windows path is LibreHardwareMonitorLib 0.9.* via the sidecar. It was used as a second opinion and checked model by model.

Every architecture it adds was already covered. Three of its choices were not followed, each pinned by a test:

• 0xAB (claimed Meteor Lake) and 0xBC (claimed Lunar Lake) appear in neither intel-family.h nor LHM's IntelCpu.cs. Two independent sources having no such model, and the PR citing none, is not enough to name a part — they report Intel (family 6h).
• 0xBE is grouped with Raptor Lake by New Intel Architectures openhardwaremonitor/openhardwaremonitor#1671; both sources call it Alder Lake-N, so the PR is the outlier.

Known, deliberately not fixed

sysinfo.rs:49 applies ExtendedModel unconditionally:

let model = (ext_model << 4) | base_model;

Intel SDM and the AMD APM both restrict it to base family 0x6 or 0xF. Benign today — every family this table names has a base family of 6 or 0xF — and it predates this PR, so it stayed out of a restore. Flagged for the architect's call.

Out of scope

Four upstream PRs cover hardware LHM 0.9.6 genuinely lacks — IT8669E (openhardwaremonitor#1384), IT8260E (openhardwaremonitor#1032), Nvidia Tesla (openhardwaremonitor#1618), Framework Chromium EC (openhardwaremonitor#1551). On Windows that layer is LibreHardwareMonitor's, so the fix belongs upstream there and arrives on the next 0.9.* bump.

Also skipped: the .NET-upgrade PRs (openhardwaremonitor#1601, openhardwaremonitor#1532, openhardwaremonitor#1352, openhardwaremonitor#1389) — the sidecar is already net8.0 — and openhardwaremonitor#1341's Stopwatch optimization, which has no Rust analogue; poll.rs already uses Instant with deadline scheduling.

Verification

• cargo test — 172 passed, 0 failed (25 in this module: 9 restored, 7 memory, 9 added)
• cargo clippy --all-targets -- -D warnings — clean
• End-to-end on a Ryzen 7 7700 (00A60F12 → family 19h, model 61h): sensorview info reports Raphael (Zen 4). The unit tests pass family/model as arguments so they run on every CI leg including aarch64; this run covers the CPUID bit-extraction path into codename_for.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SrSpbo4TKd7ZrsDZWMvjKN

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.