Both branches of the check return the same value, so the check has
no effect. Remove it and return the value directly.

This is the result of running the Coccinelle script from
scripts/coccinelle/misc/cond_return_no_effect.cocci.

Link: https://lore.kernel.org/linux-pm/20260723184538.3888637-36-ekffu200098@gmail.com/raw
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

The kernel asserted frequency from scaling_cur_freq may not always match
the hardware reported frequency from cpuinfo_cur_freq.

Print both values when they are available, and only print the unavailable
message on x86 when the hardware frequency can't be read.

Link: https://lore.kernel.org/r/20260709221344.1919794-4-jeremy.linton@arm.com
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

Now that we have a generic CPPC printout, call it on !AMD
processors. If it fails to detect CPPC, or the registers don't look
reasonable then it will exit without printing anything.

Link: https://lore.kernel.org/r/20260709221344.1919794-3-jeremy.linton@arm.com
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

Arm64 machines, and possibly others, use the standard ACPI defined CPPC
infrastructure. cpupower has CPPC support, but it's largely written
around the intricacies of AMD processors, using platform MSRs to avoid
shortcomings in the specification.

Add a generic CPPC display that depends only on standardized fields. The
computed frequency values are best effort and rely on the FW providing
optional values that can be used to derive a meaningful frequency at a
given unique performance level.

Link: https://lore.kernel.org/r/20260709221344.1919794-2-jeremy.linton@arm.com
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

extern char *optarg and extern int optind, opterr, optopt are
already declared by <getopt.h>, which is included at the top of
the file. Repeating extern declarations inside a function body
is misleading and unnecessary.

Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

On modern Intel platforms, the intel_pstate driver is commonly used and
it provides turbo boost control via
/sys/devices/system/cpu/intel_pstate/no_turbo.

However, cpupower doesn't handle this. it
1. shows turbo boost as "active" blindly for Intel platforms
2. controls turbo boost functionality via the generic
   /sys/devices/system/cpu/cpufreq/boost sysfs interface only.

Enhance the cpupower tool to ensure the "--boost" command works
seamlessly on Intel platforms with intel_pstate driver running.

Without this patch,
   $ echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo
   1
   $ sudo cpupower frequency-info --boost
   analyzing CPU 21:
     boost state support:
       Supported: yes
       Active: yes
   $ sudo cpupower set --boost 0
   Error setting turbo-boost
   $ sudo cpupower set --boost 1
   Error setting turbo-boost

With this patch,
   $ cat /sys/devices/system/cpu/intel_pstate/no_turbo
   0
   $ sudo cpupower set --boost 0
   $ sudo cpupower frequency-info --boost
   analyzing CPU 21:
     boost state support:
       Supported: yes
       Active: no
   $ cat /sys/devices/system/cpu/intel_pstate/no_turbo
   1
   $ sudo cpupower set --boost 1
   $ sudo cpupower frequency-info --boost
   analyzing CPU 28:
     boost state support:
       Supported: yes
       Active: yes
   $ cat /sys/devices/system/cpu/intel_pstate/no_turbo
   0

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

Fix error where microWatts and microJoules units were interchanged.

Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

`cpupower idle-info -o` skipped C0 because the loop began at 1:

  before:
    states:
      C1 ... latency[002] residency[00002]
      C2 ... latency[010] residency[00020]
      C3 ... latency[133] residency[00600]

  after:
    states:
      C0 ... latency[000] residency[00000]
      C1 ... latency[002] residency[00002]
      C2 ... latency[010] residency[00020]
      C3 ... latency[133] residency[00600]

Start iterating at index 0 so the idle report mirrors sysfs and
includes C0 stats.

Link: https://lore.kernel.org/r/20251202065403.1492807-1-kaushlendra.kumar@intel.com
Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

The capability check was inverted, causing the function to return
error when APERF support is available and proceed when it is not.

Negate the condition to return error only when APERF capability
is absent.

Link: https://lore.kernel.org/r/20251126091613.567480-1-kaushlendra.kumar@intel.com
Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>

The cpuidle sysfs monitor printed the previous sample’s counter
value in cpuidle_stop() instead of the freshly read one. The dprint
line used previous_count[cpu][state] while current_count[cpu][state]
had just been populated. This caused misleading debug output.

Switch the logging to current_count so the post-interval snapshot
matches the displayed value.

Link: https://lore.kernel.org/r/20251202044012.3844790-1-kaushlendra.kumar@intel.com
Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>