From nobody Fri Sep 25 16:51:46 2026 Received: from outbound.baidu.com (mx16.baidu.com [111.202.115.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F475470137; Thu, 10 Sep 2026 11:15:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=111.202.115.101 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789038954; cv=none; b=VHc7Lj9BmLu1zjC5mVuYGIn0HAkqlZE5jyuk4gsr1oEl8WeD24aQH6ABt6Dkjf9yCHO1wVrbvA9MnoL7BVLa7K/htVBfR788WSr2ikBauRdOG1+m99kd2BfAnh2TKL8AE1VYXCthCOm7Ms09N+GSzFeYSI/3TvOxeb5m8UtMlSc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789038954; c=relaxed/simple; bh=lRF7Dl5bp2u7TMi46n+iGbduop9cF1vcUheNOrG7UoM=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=o5AXfUWXoSpp0tw7cnCXuJTH3OEKqGZzmwWUJQpPbI9g14sdRgpN6H5WMYB+AhmL7aqoKLKra+06n+v+uwkAbADpxEuxXtf+VOTrLefIdbt94DV0FOnQpghLxFn6M+o0IaZRoI094hyL2HFlAh5tKAyrekCOXqoUY8Cu4DssAgQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=baidu.com; spf=pass smtp.mailfrom=baidu.com; dkim=pass (2048-bit key) header.d=baidu.com header.i=@baidu.com header.b=Z/Ji7Ktx; arc=none smtp.client-ip=111.202.115.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=baidu.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baidu.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baidu.com header.i=@baidu.com header.b="Z/Ji7Ktx" X-MD-Sfrom: lirongqing@baidu.com X-MD-SrcIP: 172.31.50.47 From: lirongqing To: "Rafael J . Wysocki" , Viresh Kumar , , CC: , Li RongQing Subject: [PATCH v4 1/2] cpufreq: acpi-cpufreq: fix P-state index mismatch in extract_io() Date: Thu, 10 Sep 2026 19:13:28 +0800 Message-ID: <20260910111329.2220-2-lirongqing@baidu.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20260910111329.2220-1-lirongqing@baidu.com> References: <20260910111329.2220-1-lirongqing@baidu.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: bjkjy-exc8.internal.baidu.com (172.31.50.52) To bjkjy-exc3.internal.baidu.com (172.31.50.47) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baidu.com; s=selector1; t=1789038822; bh=RpVinj4s0Rh3TFJZafzq4jkBDp+N9yNwbfL62hb/wKU=; h=From:To:CC:Subject:Date:Message-ID:Content-Type; b=Z/Ji7Ktxd+cz4db5O+zKJhPYN5AYBi/uj+wpamNPoGALZD8GYYhd5fnus5jV5eoK+ ndEvWBcOhw39TA6w0AOAAO9cBqf8F8NDxvH6IXm1npq2tMOb/+uz1IbL9pJ0i8/xrA HoTJ0w+kH/ibGtqRIDyrjLCxtYt73yNWhdqIpKxlWCwWR2Ldr7Ei/ODBBxWRv6+geR iu1HqoCLq906vkvOJ62eSZTQjmUDIZ/4mBNPCKn3EKS1UWJpJ+xwnmoq9DlNJQNUfK VIu7GAtPY3LaxUJFUlNhzEl+J0OJRqYQQEw3VJBHlEwl3hg//82rEM87ssTrp/x8bO hul7BtDvVQZeg== Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Li RongQing When policy->freq_table is built in acpi_cpufreq_cpu_init(), entries that are not lower in frequency than the previous one are skipped. For each remaining entry, freq_table[].driver_data stores the original ACPI P-state index, so the index space of freq_table no longer matches perf->states[]. extract_io() currently walks perf->states[] with index i and uses the same i to index policy->freq_table[i]. When duplicate frequencies exist, this can associate a P-state status with the frequency of a different P-state. It can also access an invalid or sentinel entry in freq_table when the number of entries in perf->states[] is greater than the number of entries remaining in the frequency table. extract_io() is used on ACPI_ADR_SPACE_SYSTEM_IO platforms by the frequency verification path, which is enabled by the acpi_pstate_strict module parameter. With the mismatched lookup, check_freqs() can fail to match the frequency of the P-state that drv_write() has already programmed. It then sleeps through all 100 iterations - at least ~1 ms of usleep_range() plus 100 cross-CPU calls and I/O port reads, all with policy->rwsem held, and .target_index() returns -EAGAIN, leaving perf->state at its previous value while the hardware is running at the newly requested P-state. The cpufreq core consequently keeps policy->cur at the old frequency. Since __cpufreq_driver_target() returns early when the requested frequency equals policy->cur, the driver is not called again for that frequency and the control register is not rewritten. The hardware can therefore remain at a frequency that differs from the frequency known to the cpufreq core. Fix this by iterating over policy->freq_table and using pos->driver_data as the original ACPI P-state index when accessing perf->states[], as extract_msr() already does. Fixes: fe27cb358835 ("[CPUFREQ][2/8] acpi: reorganize code to make MSR supp= ort addition easier") Signed-off-by: Li RongQing Reviewed-by: Zhongqiu Han --- drivers/cpufreq/acpi-cpufreq.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c index 10ea603..a797bb2 100644 --- a/drivers/cpufreq/acpi-cpufreq.c +++ b/drivers/cpufreq/acpi-cpufreq.c @@ -197,14 +197,13 @@ static unsigned extract_io(struct cpufreq_policy *pol= icy, u32 value) { struct acpi_cpufreq_data *data =3D policy->driver_data; struct acpi_processor_performance *perf; - int i; + struct cpufreq_frequency_table *pos; =20 perf =3D to_perf_data(data); =20 - for (i =3D 0; i < perf->state_count; i++) { - if (value =3D=3D perf->states[i].status) - return policy->freq_table[i].frequency; - } + cpufreq_for_each_entry(pos, policy->freq_table) + if (value =3D=3D perf->states[pos->driver_data].status) + return pos->frequency; return 0; } =20 --=20 2.9.4 From nobody Fri Sep 25 16:51:46 2026 Received: from outbound.baidu.com (mx21.baidu.com [220.181.3.85]) by smtp.subspace.kernel.org (Postfix) with SMTP id 7E82F3DC4D9; Thu, 10 Sep 2026 11:13:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.181.3.85 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789038833; cv=none; b=Vxa6gfWRWrAH1uCaWeC6dE6SG2P4ouTpV8eDFk2AHlnCCwrcbZmc8Uqv7+oxQT88GxGQ1hFFmgmb8LbpAbKja2wp5UjAmQ3pnEsYbDkTWYQ2JYly8osoj9yCGmau4HEDTTAp6KA977ihF0wMnmt9yzeV9/DUUZAEqPFmMSY3Thk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789038833; c=relaxed/simple; bh=XW27UNJj4UA14533Amues/sb6SkLvzOt5/CbLxNkvAs=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=kS8w+/OwWsDdwy500gnZz8pUghgQjISgtQW7gYjWL41Hm6Aj69dVQPoEPcLowCD9tIB/uIYwY+xgNni7GrtwcK5Ui1PargKTT869wym5JsUXE1YttmU6bhyqZZDX4j1UMuxTVg4FsCBNzdZL8SklZsNAQZ0yOAr/Rg26irMfUh4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=baidu.com; spf=pass smtp.mailfrom=baidu.com; dkim=pass (2048-bit key) header.d=baidu.com header.i=@baidu.com header.b=jBZMrbEF; arc=none smtp.client-ip=220.181.3.85 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=baidu.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baidu.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baidu.com header.i=@baidu.com header.b="jBZMrbEF" X-MD-Sfrom: lirongqing@baidu.com X-MD-SrcIP: 172.31.50.47 From: lirongqing To: "Rafael J . Wysocki" , Viresh Kumar , , CC: , Li RongQing Subject: [PATCH v4 2/2] cpufreq: acpi-cpufreq: fix P-state index mismatch in get_cur_freq_on_cpu() Date: Thu, 10 Sep 2026 19:13:29 +0800 Message-ID: <20260910111329.2220-3-lirongqing@baidu.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20260910111329.2220-1-lirongqing@baidu.com> References: <20260910111329.2220-1-lirongqing@baidu.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: bjkjy-exc8.internal.baidu.com (172.31.50.52) To bjkjy-exc3.internal.baidu.com (172.31.50.47) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baidu.com; s=selector1; t=1789038824; bh=Rx2QJJMhXAylfuPrngq3kyadaNnt5gAa5fGnjzTmr3g=; h=From:To:CC:Subject:Date:Message-ID:Content-Type; b=jBZMrbEFyRPwL/fXTsqOpp0rQUhbeWKbI5ffBqM4r+zm0HbUAKNW3DQWzjqwPE2Zn XnV+Q2Bk2VW/S78hsd5E/4/1XpOB+rhMK30EBBbGPUbZxRqkivGghZWAhue/G9SatZ cjn0GXhlKllK2LhL0pkH3ox0OTep0rghgNKk5Zr4U15vDQ2T4wa3HB9X+CLo8zZdat 4WHkYnwtloRrGdnwTUFUwMKyuL5u1O5KHLiD1yPHUbiGTGRd0uphUEPDsiRAQrT/7G IonMss2rLMzaHRkgjrzkpCV+TJm0DOhDwB4OMW4mvE7ZUIQlavCH3NqocIvUOIl+lJ 4XAd6MgIki5kw== Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Li RongQing get_cur_freq_on_cpu() uses perf->state, which is an index into perf->states[], to index policy->freq_table[]. However, freq_table[] is built by filtering _PSS entries that are not lower in frequency than the previous one, so its index space no longer matches perf->states[]. The original P-state index for each remaining freq_table entry is stored in driver_data. Once an entry has been skipped, using perf->state as an index into freq_table[] can therefore select the frequency of a different P-state. The reported current frequency itself remains correct because it is obtained from extract_freq(). The mismatch only affects the cached frequency used by get_cur_freq_on_cpu() to detect a firmware frequency change behind our back. If the wrong table entry contains a frequency different from the one the CPU is actually running at, the check falsely detects a frequency change and sets data->resume. The next ->target() call then performs a redundant control-register write even if the requested P-state is already the current P-state. Conversely, if the wrong table entry happens to contain the frequency to which firmware has changed the CPU, the frequency change is missed and data->resume remains clear. A subsequent ->target() call for the P-state that the cpufreq core believes to be current can then short-circuit without rewriting the control register, leaving the CPU at the firmware-selected frequency until a different P-state is requested. Fix this by taking the cached frequency directly from perf->states[perf->state].core_frequency. perf->state and perf->states[] use the same P-state index space, and converting core_frequency to kHz yields the same value stored in the corresponding freq_table entry during initialization. Fixes: e56a727b023d ("[CPUFREQ] Make acpi-cpufreq more robust against BIOS = freq changes behind our back.") Reported-by: Zhongqiu Han Suggested-by: Zhongqiu Han Signed-off-by: Li RongQing Reviewed-by: Zhongqiu Han --- drivers/cpufreq/acpi-cpufreq.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c index a797bb2..3313c74 100644 --- a/drivers/cpufreq/acpi-cpufreq.c +++ b/drivers/cpufreq/acpi-cpufreq.c @@ -353,6 +353,7 @@ static u32 get_cur_val(const struct cpumask *mask, stru= ct acpi_cpufreq_data *dat =20 static unsigned int get_cur_freq_on_cpu(unsigned int cpu) { + struct acpi_processor_performance *perf; struct acpi_cpufreq_data *data; struct cpufreq_policy *policy; unsigned int freq; @@ -368,7 +369,9 @@ static unsigned int get_cur_freq_on_cpu(unsigned int cp= u) if (unlikely(!data || !policy->freq_table)) return 0; =20 - cached_freq =3D policy->freq_table[to_perf_data(data)->state].frequency; + perf =3D to_perf_data(data); + cached_freq =3D perf->states[perf->state].core_frequency * 1000; + freq =3D extract_freq(policy, get_cur_val(cpumask_of(cpu), data)); if (freq !=3D cached_freq) { /* --=20 2.9.4