linux-kernel - [PATCH] docs: cpufreq: Frequencies are in Hz, not kHz

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed,  1 Feb 2023 10:11:19 -0800
From:   Douglas Anderson <dianders@...omium.org>
To:     rafael@...nel.org, viresh.kumar@...aro.org, corbet@....net
Cc:     Douglas Anderson <dianders@...omium.org>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-pm@...r.kernel.org
Subject: [PATCH] docs: cpufreq: Frequencies are in Hz, not kHz

Though the documentation for the cpufreq files has always specified
that the frequencies are in kHz, they simply aren't. For as long as I
can remember looking at these files they've always been in straight
Hz. Fix the docs.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
Signed-off-by: Douglas Anderson <dianders@...omium.org>
---
NOTE: git blame shows that this has been wrong since before the kernel
switched to git. I've tagged the first git commit as Fixes, but we
could easily just drop the Fixes tag if that's a better way to go.

 Documentation/admin-guide/pm/cpufreq.rst | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/admin-guide/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst
index 6adb7988e0eb..eb46c5983a0a 100644
--- a/Documentation/admin-guide/pm/cpufreq.rst
+++ b/Documentation/admin-guide/pm/cpufreq.rst
@@ -242,7 +242,7 @@ are the following:
 
 ``cpuinfo_cur_freq``
 	Current frequency of the CPUs belonging to this policy as obtained from
-	the hardware (in KHz).
+	the hardware (in Hz).
 
 	This is expected to be the frequency the hardware actually runs at.
 	If that frequency cannot be determined, this attribute should not
@@ -250,11 +250,11 @@ are the following:
 
 ``cpuinfo_max_freq``
 	Maximum possible operating frequency the CPUs belonging to this policy
-	can run at (in kHz).
+	can run at (in Hz).
 
 ``cpuinfo_min_freq``
 	Minimum possible operating frequency the CPUs belonging to this policy
-	can run at (in kHz).
+	can run at (in Hz).
 
 ``cpuinfo_transition_latency``
 	The time it takes to switch the CPUs belonging to this policy from one
@@ -278,7 +278,7 @@ are the following:
 	listed by this attribute.]
 
 ``scaling_cur_freq``
-	Current frequency of all of the CPUs belonging to this policy (in kHz).
+	Current frequency of all of the CPUs belonging to this policy (in Hz).
 
 	In the majority of cases, this is the frequency of the last P-state
 	requested by the scaling driver from the hardware using the scaling
@@ -308,7 +308,7 @@ are the following:
 
 ``scaling_max_freq``
 	Maximum frequency the CPUs belonging to this policy are allowed to be
-	running at (in kHz).
+	running at (in Hz).
 
 	This attribute is read-write and writing a string representing an
 	integer to it will cause a new limit to be set (it must not be lower
@@ -316,7 +316,7 @@ are the following:
 
 ``scaling_min_freq``
 	Minimum frequency the CPUs belonging to this policy are allowed to be
-	running at (in kHz).
+	running at (in Hz).
 
 	This attribute is read-write and writing a string representing a
 	non-negative integer to it will cause a new limit to be set (it must not
@@ -326,7 +326,7 @@ are the following:
 	This attribute is functional only if the `userspace`_ scaling governor
 	is attached to the given policy.
 
-	It returns the last frequency requested by the governor (in kHz) or can
+	It returns the last frequency requested by the governor (in Hz) or can
 	be written to in order to set a new frequency for the policy.
 
 
-- 
2.39.1.456.gfc5497dd1b-goog