[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201207223057.GJ20489@zn.tnic>
Date: Mon, 7 Dec 2020 23:30:57 +0100
From: Borislav Petkov <bp@...en8.de>
To: Wei Huang <whuang2@....com>
Cc: Punit Agrawal <punitagrawal@...il.com>, rjw@...ysocki.net,
wei.huang2@....com, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, x86@...nel.org
Subject: Re: [RFC PATCH 2/4] cpufreq: acpi-cpufreq: Add processor to the
ignore PSD override list
On Mon, Dec 07, 2020 at 04:07:52PM -0600, Wei Huang wrote:
> I think we shouldn't override zen2 if _PSD is correct. In my opinion,
> there are two approaches:
>
> * Keep override_acpi_psd()
> Let us keep the original quirk and override_acpi_psd() function. Over
> the time, people may want to add new CPUs to override_acpi_psd(). The
> maintainer may declare that only CPUs >= family 17h will be fixed, to
> avoid exploding the check-list.
>
> * Remove the quirk completely
> We can completely remove commit acd316248205 ("acpi-cpufreq: Add quirk
> to disable _PSD usage on all AMD CPUs")? I am not sure what "AMD desktop
> boards" was referring to in the original commit message of acd316248205.
> Maybe such machines aren't in use anymore.
* Third option: do not do anything. Why?
- Let sleeping dogs lie and leave the workaround acd316248205 for old
machines.
- Make a clear cut that the override is not needed from Zen3 on, i.e.,
your patch
5368512abe08 ("acpi-cpufreq: Honor _PSD table setting on new AMD CPUs")
Punit's commit message reads "...indicates that the override is not
required for Zen3 onwards, it seems that domain information can be
trusted even on certain earlier systems."
That's not nearly a justification in my book to do this on anything < Zen3.
This way you have a clear cut, you don't need to deal with adding any
more models to override_acpi_psd() and all is good.
Unless there's a better reason to skip the override on machines < Zen3
but I haven't heard any so far...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists