Hi,
Am Mon, Sep 26, 2022 at 10:02:44PM +0530 schrieb K Prateek Nayak:
Hello Peter,
On 9/26/2022 5:37 PM, Peter Zijlstra wrote:
For how many of the above have you changed behaviour?
The proposed logic does alter the behavior for x86 chipsets that depend on acpi_idle driver and have IOPORT based C-state. Based on what Rafael and Dave suggested, I have marked all Intel processors to be affected by this bug. In light of Andreas' report, I've also marked all the pre-family 17h AMD processors to be affected by this bug to avoid causing any regression.
It is hard to tell if any other vendor had this bug in their chipsets. Dave's patch does not make this consideration either and limits the dummy operation to only Intel chipsets using acpi_idle driver. (https://lore.kernel.org/all/78d13a19-2806-c8af-573e-7f2625edfab8@intel.com/) If folks reported a regression, I would have been happy to fix it for them.
Despite certain, umm, controversies, the discussion/patch activities appear to be heading into a good direction ;)
This text somehow prompted me to think of whether STPCLK# [quirk] behaviour is a property of the CPU family, or the chipset, or actually a combination of it.
Given that [from recollection] VIA 8233/8235 spec PDFs do mention STPCLK#, possibly a chipset does have a say in it? (which obviously would then mean that the kernel's quirk state decision-making would have to be refined)
Minor reference (note 8237, not 8233): http://www.chipset-ic.com/datasheet/VT8237.pdf "STPCLK# is asserted by the VT8237R to the CPU to throttle the processor." (and many other STPCLK# mentions there)
Greetings
Andreas Mohr