From nobody Tue Sep 29 02:34:37 2026 Received: from outbound.baidu.com (mx16.baidu.com [111.202.115.101]) by smtp.subspace.kernel.org (Postfix) with SMTP id 17DED38239F; Thu, 13 Aug 2026 09:02:00 +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=1786611732; cv=none; b=tlQYXhH2qhQ+nhYFxaAkuaSfTPYJNh4Q0UsvQDsoQBKsaICoQCmPAkYnigxE9AYYTPBhgpwz5cgeaU4yipn6PIH2fpJb4AhWDda3cIg5TKRPkIASbqvocnUtPmV5Lv56WOWr14Ry9WHH2LNQwq5iV/U6hb3iAaAcuKYJ5TSgBzo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786611732; c=relaxed/simple; bh=3ngXCeyvGnHfWKSqJVpav60LYKdm6LAbQLhsgQ8Fruw=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mpCn3IXV2TvbZYTXdKDXe6tfATeWwiWUY8ZPeGE2Rgu3sfRdnh7srw/+B8YQpMvux5lZjfyxi9Tr4ywW+J+WZDx8z5EP4LqENjPq1tLNHY83iA9kCjjag3RLlKSCj3QUuT4rWKPMD4JeJiDfLbrh4ZdA2L409sc2OQX28JCC3SE= 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=VfkyoseM; 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="VfkyoseM" 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 v2 1/2] cpufreq: acpi-cpufreq: fix P-state index mismatch in extract_io() Date: Thu, 13 Aug 2026 17:01:44 +0800 Message-ID: <20260813090145.2450-2-lirongqing@baidu.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20260813090145.2450-1-lirongqing@baidu.com> References: <20260813090145.2450-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: bjhj-exc6.internal.baidu.com (172.31.3.16) 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=1786611718; bh=RiA2nDSsa39q/3zStCXF8prWJYGTHdP7bM/LW+mUF4c=; h=From:To:CC:Subject:Date:Message-ID:Content-Type; b=VfkyoseMZNbGcmsmi8xDLqI7h1ZtqlLxamcM0tVIiAGCJug7nzFE8c7PPnyD7rtE0 A5QWLV2eIJfsaVOB3Rsv9DaL39+7KBwVdxuTOs8eXhSmV1uBqvr+bklQa6xhlvWDj/ fqnT34N+4Ytxc57YkTroYWJAQoD6v+yM2mGk0jlsGUTEqGPkjz+WD4HJlWPmUaqr5L mjls8nNtoQiw3CUeZwR3EPf9LCsYV3AcGe2hCq3LzZRrLO/gOzqqctF31vx7s111bZ wOdOdT8DjWRtnVx2+1H/l8PKFwjLDxE/Zvt5v+TZejPbZQjsprIURmQ7Dm0i1kF+XU aiZA7/k8O7rgw== 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 with duplicate frequencies are skipped. The original P-state index for each remaining entry is stored in freq_table[].driver_data, so the index space of freq_table no longer matches perf->states[]. extract_io() walks perf->states[] with index i and uses the same i to index policy->freq_table[i]. This causes two problems when duplicate frequencies exist: - Returning the frequency of the wrong P-state - Returning 0 from a zeroed tail entry, or even CPUFREQ_TABLE_END (~1u) reported as 0xfffffffe kHz Fix it by walking policy->freq_table with cpufreq_for_each_entry() and using perf->states[pos->driver_data].status, aligning with extract_msr(). Fixes: 8cee1eed8e78 ("cpufreq: ACPI: Remove freq_table from acpi_cpufreq_da= ta") Signed-off-by: Li RongQing --- 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 21639d9..1abe9ab 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 Tue Sep 29 02:34:37 2026 Received: from outbound.baidu.com (mx14.baidu.com [220.181.3.101]) by smtp.subspace.kernel.org (Postfix) with SMTP id E2F573BB695; Thu, 13 Aug 2026 09:02:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.181.3.101 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786611736; cv=none; b=K1PNosoi/fVcXVgn9qRWcImEgxvgxITte3BpVinx83Sj2X8IFm2Qt0CsKum2wLKgHGj/pKCEYPc9WrWkSWsvkpEbUS1Q7juOUJQ9w6FeV3jvCkq5SyAsoF7+DOne/hRLHRb8mqI3zGJxK2CU4LMLHb4LcVRL5iEIUBkl/BsX+/E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786611736; c=relaxed/simple; bh=bIr/p85eWcrzYTDGgQ7gg2TlhCD/3+BMk3WjJ0L5W48=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NTs+1ycfK3ObMvFPihBUb80rB/6PXdvfNyswcqHbM64zrCs/aBaXpvV8uRWuNOZi3ibLLSpCQIp9OPljHrbdQS8zOexDFeSWlbQGCdAlxzTvYiUAZD2xsLhdI+W18UxehSRzc651EihQ8joQ0UYjBwfkcgYDdznrUSRTBIitfMc= 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=XGT34wyP; arc=none smtp.client-ip=220.181.3.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="XGT34wyP" 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 v2 2/2] cpufreq: acpi-cpufreq: fix P-state index mismatch in get_cur_freq_on_cpu() Date: Thu, 13 Aug 2026 17:01:45 +0800 Message-ID: <20260813090145.2450-3-lirongqing@baidu.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20260813090145.2450-1-lirongqing@baidu.com> References: <20260813090145.2450-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: bjhj-exc6.internal.baidu.com (172.31.3.16) 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=1786611720; bh=7nb6pHn3wIgssKvXSPIW7xprcyR8CB87q1gbn7EoJbY=; h=From:To:CC:Subject:Date:Message-ID:Content-Type; b=XGT34wyPIhf42PLjBjwyw55D8+nqQ6tJfRcG+hNL3MJeAWsIT0MqwcYKjOKrLKIvV WETaixWTZ27t3iIR8M1Ob9lqQ1nei1QhXDqtq2GKZscIN0eiUuHxtzg6X9B40tgavy WRSYcwZO73PSw8Cl3Qkl8ewiunvj2G8U768ES4ZJFO/JgKG1/m4h+ZRt5GZuQlocxJ WHTUhxAM/450OvflgPehJgR3e1ZfPfKdxGN6jLL7rpnCFUPA5ZWW9Q4jNnS9b+irUT lymMBFo09YzWRcTBHJdNu0eP/tAjnRdWKLBiFe6XKjUoWHTLq8DTeN35qMlgybUlD3 xJaz5TtbaNW9A== Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Li RongQing get_cur_freq_on_cpu() reads the cached frequency as policy->freq_table[to_perf_data(data)->state], mixing two different index spaces: perf->state indexes perf->states[], while policy->freq_table[] is built with duplicate frequencies removed and stores the original P-state index in freq_table[].driver_data. Once any _PSS entry has been skipped the two arrays no longer line up, so the cached frequency used to detect a "BIOS changed frequency behind our back" event could be taken from the wrong table slot. Look up the freq_table entry whose driver_data matches perf->state instead of indexing freq_table[] with perf->state directly. Fixes: 8cee1eed8e78 ("cpufreq: ACPI: Remove freq_table from acpi_cpufreq_da= ta") Reported-by: Zhongqiu Han Signed-off-by: Li RongQing --- drivers/cpufreq/acpi-cpufreq.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c index 1abe9ab..61ede49c 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 cpufreq_frequency_table *pos; struct acpi_cpufreq_data *data; struct cpufreq_policy *policy; unsigned int freq; @@ -368,7 +369,13 @@ static unsigned int get_cur_freq_on_cpu(unsigned int c= pu) if (unlikely(!data || !policy->freq_table)) return 0; =20 - cached_freq =3D policy->freq_table[to_perf_data(data)->state].frequency; + cached_freq =3D 0; + cpufreq_for_each_entry(pos, policy->freq_table) + if (pos->driver_data =3D=3D to_perf_data(data)->state) { + cached_freq =3D pos->frequency; + break; + } + freq =3D extract_freq(policy, get_cur_val(cpumask_of(cpu), data)); if (freq !=3D cached_freq) { /* --=20 2.9.4