✨ Identify current CPUs instead of calling them all "Intel Core"

[manupawickramasinghe]

Merge order: #32 (unbreaks currently-red CI) → #28 → #29 → #30 → #31. Each is independently reviewable; the order just keeps the checks readable.

The bug

codename_for decoded the CPUID model byte at sysinfo.rs:47-49 and then threw it away for Intel, matching on the family alone:

match family {
    0x6 => "Intel Core",
    _ => "",
}

Family 6 has carried every Intel part from the Pentium Pro to Panther Lake. So a Core 2 Duo, a 14900K and a Core Ultra 9 all rendered the identical string — and so did every Atom, which is not a vaguer answer but a wrong one.

AMD had the opposite failure:

(0x1a, _) => "Granite Ridge (Zen 5)",
(0x17, _) => "Matisse/Renoir (Zen 2)",

Family 1Ah is all of Zen 5, so a Strix Point laptop and a Turin server both claimed to be a Granite Ridge desktop. (0x17, _) likewise called a first-generation Summit Ridge Ryzen a Zen 2 part.

The fix

Both vendors now match on family and model, split into intel_codename and amd_codename.

Sourcing — the actual constraint

A wrong codename is worse than a blank one: it renders in the System Summary directly beside the CPUID signature a user can check it against. So nothing in these tables is written from recall. Every entry is citable:

Range	Source
Intel through Tiger Lake / Comet Lake	this repo's own Hardware/CPU/IntelCPU.cs — the OpenHardwareMonitor detection these sources are a port of
Intel from Rocket Lake onward, plus Atom and Xeon	Linux kernel arch/x86/include/asm/intel-family.h
AMD	libcpuid recog_amd.c

Worth knowing: the C# tree has no AMD codenames at all — a repo-wide search turns up only six brand-string literals for Tctl offsets. The AMD entries that were already in this file were unsourced relative to this repository, which is how (0x1a, _) came to over-claim. They are now pinned to libcpuid's family/model values.

Two things this surfaced

Intel is leaving family 6. Nova Lake is family 12h and Diamond Rapids 13h. Matching on family == 0x6 returned "" for both, so the new table matches on the family rather than assuming it. The family/model arithmetic itself needed no change — it already matches the kernel's x86_family()/x86_model() exactly.

Unknown models degrade to something still true. AMD does not mix generations within a family — 17h is Zen…Zen 2, 19h is Zen 3 and Zen 4, 1Ah is Zen 5 throughout — so each family arm ends in a generation-level catch-all. A part released after this table was written reports Zen 5 rather than a wrong codename or a blank. Unknown Intel family-6 models fall back to Intel (family 6h) — deliberately not Intel Core, since family 6 carries every Atom too and that would be a wrong brand rather than a cautious one. Unknown vendors return "".

Verification

• 9 new tests, all passing. They pass family and model as arguments rather than executing CPUID, so they run on every CI leg including aarch64.
• cargo clippy --all-targets -- -D warnings clean on --no-default-features and on gui.
• Verified end-to-end on real hardware: a Ryzen 7 7700 (CPUID 00A60F12 → family 19h, model 61h) still reports Raphael (Zen 4) via sensorview info.

CPU
  Cores / Threads 8 / 16
  Codename        Raphael (Zen 4)
  Vendor          AuthenticAMD

Not in scope

The wider audit turned up related items left for separate PRs — chiefly the SMBIOS memory-type table, which decodes only DDR3/4/5 and renders soldered-LPDDR laptops as the literal string "DRAM SDRAM".

🤖 Generated with Claude Code

[Copilot]

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

[manupawickramasinghe]

The Windows and macOS checks here are red for a reason that has nothing to do with this PR: both fail at the Clippy step on error: using chunks_exact with a constant chunk size, inherited from master. That is Rust 1.98's new clippy::chunks_exact_to_as_chunks lint meeting CI's -D warnings — see #32, which fixes it.

Confirmed by reading the failing logs: the lint fires in src/source/firmware.rs (Windows) and src/source/macos/dvfs.rs (macOS), neither of which this PR touches. The Linux leg, where neither file compiles, is green.

Merge #32 first and these go green on a rebase.