Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Giovanni Gherdovich]

Hello Mario,

[moving Kyle to BCC, I hope it's OK]

in my last message I forgot to reply to the rest of your questions;
see below. In any event, next step for me is testing the latest bios,
as there seems to be an update.

On Wed Oct 7, 2026 16:56, Mario Limonciello wrote:
> Can you please add more information about the vendor/model of the MB, etc?

right.

Motherboard is MSI, model is TRX40 PRO WIFI, CPU is AMD Ryzen Threadripper 3960X.
https://www.msi.com/Motherboard/TRX40-PRO-WIFI
Practically the same system as Kyle.

> > amd-pstate requires explicit knowledge of nominal frequency, so it
> > can't load on this hardware. The driver already has a mechanism (the
> > so-called "quirks") to accommodate for missing nominal freq in ACPI
> > tables, so here we use it to match against CPU family, model, core
> > count, and BIOS version.
>
> Yeah; it's intended for this specific case of really old hardware that the BIOS isn't going to fix it.
>
> I don't understand why core count matters though.

My thinking was:

1. I want to make the "quirk" to match as many chips as possible, to
   make it more useful and worthwhile.
2. The doc I have, "Power and Thermal Data Sheet" (publication #56736
   in the AMD doc library), is for family 0x17, models 0x30-0x3F
   processors.
3. Problem: these have different nominal frequencies, depending on the
   core count. Specifically:
   24 cores: 3800 MHz (like the Ryzen 3090x I need)
   32 cores: 3700 Mhz
   64 cores: 2900 MHz
4. Thus I decided to match for family 0x17, model 0x30-0x3f, 24 cores.
   Without the core count constraint, I couldn't tell which of the
   three nominal frequencies above should apply.

> > @@ -174,6 +179,22 @@ static int __init dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
> >       return 0;
> >   }
> > +static int __init dmi_matched_trx40_bios_bug(const struct dmi_system_id *dmi)
> > +{
> > +    /**
> > +     * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 socket / TRX40 chipset.
> > +     */
> > +    if (boot_cpu_data.x86 == 0x17 &&
> > +        boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model <= 0x3F &&
> > +        topology_num_cores_per_package() == 24) {
>
> Does the number of cores actually matter?  Do you mean to say if you swap the CPU to another part CPPC works?

No no. It was either wide matching (models 0x30-0x3f) but constraint
on #cores, or narrow matching for the exact CPU in my motherboard, (model 0x31).
Since I'm hard-coding data into the kernel, I figured wide matching
would make the quirk more applicable to potentially other affected
systems, hence more useful.

> > +        quirks = dmi->driver_data;
> > +        pr_info("Overriding nominal and lowest frequencies for %s\n", dmi->ident);
>
> The BIOS bug specifically is lack of values, not invalid values, right? Just want to make sure I'm following this right.

Correct, BIOS is lacking the values. That info message "Overriding"
is taken verbatim from the other "quirk" in the source, but strictly
speaking inaccurate. Values weren't there to begin with.

All that said, I've asked the openSUSE user to test the newer BIOS,
we'll see what that gives.


Thanks,
Giovanni