On some systems the nominal_perf value retrieved via CPPC is just a constant and fetching it doesn't require accessing any registers, so if it is the only CPPC capability that's needed, it is wasteful to run cppc_get_perf_caps() in order to get just that value alone, especially when this is done for CPUs other than the one running the code. For this reason, introduce cppc_get_nominal_perf() allowing nominal_perf to be obtained individually, by generalizing the existing cppc_get_desired_perf() (and renaming it) so it can be used to retrieve any specific CPPC capability value. While at it, clean up the cppc_get_desired_perf() kerneldoc comment a bit. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* acpi-misc: ACPI: dock: fix some coding style issues ACPI: sysfs: fix some coding style issues ACPI: PM: add a missed blank line after declarations ACPI: custom_method: fix a coding style issue ACPI: CPPC: fix some coding style issues ACPI: button: fix some coding style issues ACPI: battery: fix some coding style issues ACPI: acpi_pad: add a missed blank line after declarations ACPI: LPSS: add a missed blank line after declarations ACPI: ipmi: remove useless return statement for void function ACPI: processor: fix some coding style issues ACPI: APD: fix a block comment align issue ACPI: AC: fix some coding style issues ACPI: fix various typos in comments
All of the CPPC sysfs show functions are called via indirect call in
kobj_attr_show(), where they should be of type
ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr, char *buf);
because that is the type of the ->show() member in
'struct kobj_attribute' but they are actually of type
ssize_t (*show)(struct kobject *kobj, struct attribute *attr, char *buf);
because of the ->show() member in 'struct cppc_attr', resulting in a
Control Flow Integrity violation [1].
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf
3400
$ dmesg | grep "CFI failure"
[ 175.970559] CFI failure (target: show_highest_perf+0x0/0x8):
As far as I can tell, the only difference between 'struct cppc_attr'
and 'struct kobj_attribute' aside from the type of the attr parameter
is the type of the count parameter in the ->store() member (ssize_t vs.
size_t), which does not actually matter because all of these nodes are
read-only.
Eliminate 'struct cppc_attr' in favor of 'struct kobj_attribute' to fix
the violation.
[1]: https://lore.kernel.org/r/20210401233216.2540591-1-samitolvanen@google.com/
Fixes: 158c998ea44b ("ACPI / CPPC: add sysfs support to compute delivered performance")
Link: https://github.com/ClangBuiltLinux/linux/issues/1343
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fix some coding style issues reported by checkpatch.pl, including the following types: WARNING: Missing a blank line after declarations WARNING: unnecessary whitespace before a quoted newline ERROR: spaces required around that '>=' ERROR: switch and case should be at the same indent Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
For convenience, add empty stubs of library functions defined in cppc_acpi.c for the CONFIG_ACPI_CPPC_LIB unset case. Because one of them needs to return CPUFREQ_ETERNAL, include linux/cpufreq.h into the CPPC library header file and drop the direct inclusion of it from cppc_acpi.c. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com>
Fix trivial ACPI driver comment typos. s/notifcations/notifications/ s/Ajust/Adjust/ s/preform/perform/ s/atrributes/attributes/ s/Souce/Source/ s/Evalutes/Evaluates/ s/Evalutes/Evaluates/ s/specifiy/specify/ s/promixity/proximity/ s/presuambly/presumably/ s/Evalute/Evaluate/ s/specificed/specified/ s/rountine/routine/ s/previosuly/previously/ Change comment referencing pcc_send_cmd to send_pcc_cmd. Signed-off-by: Tom Saeger <tom.saeger@oracle.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Properly initialise vaddr pointers in cpc_read() and cpc_write() to NULL instead of 0. This fixes the following sparse warnings: drivers/acpi/cppc_acpi.c:937:31: warning: Using plain integer as NULL pointer drivers/acpi/cppc_acpi.c:982:31: warning: Using plain integer as NULL pointer Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ppc_comm_addr is a virtual address to the PCC space and it's annotated with __iomem. Therefore, generic_comm_base which gets assigned the value of pcc_comm_address should be annotated as well. This already happens in check_pcc_chan(), but not in send_pcc_cmd(), which results in the following sparse warnings: drivers/acpi/cppc_acpi.c:237:18: warning: cast removes address space '__iomem' of expression drivers/acpi/cppc_acpi.c:299:9: warning: incorrect type in argument 2 (different address spaces) drivers/acpi/cppc_acpi.c:299:9: expected void volatile [noderef] __iomem *addr drivers/acpi/cppc_acpi.c:299:9: got unsigned short * drivers/acpi/cppc_acpi.c:302:9: warning: incorrect type in argument 2 (different address spaces) drivers/acpi/cppc_acpi.c:302:9: expected void volatile [noderef] __iomem *addr drivers/acpi/cppc_acpi.c:302:9: got unsigned short * Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* pm-cpufreq: cpufreq: intel_pstate: Use most recent guaranteed performance values cpufreq: intel_pstate: Implement the ->adjust_perf() callback cpufreq: Add special-purpose fast-switching callback for drivers cpufreq: schedutil: Add util to struct sg_cpu cppc_cpufreq: replace per-cpu data array with a list cppc_cpufreq: expose information on frequency domains cppc_cpufreq: clarify support for coordination types cppc_cpufreq: use policy->cpu as driver of frequency setting ACPI: processor: fix NONE coordination for domain mapping failure ACPI: processor: Drop duplicate setting of shared_cpu_map
The cppc_cpudata per-cpu storage was inefficient (1) additional to causing
functional issues (2) when CPUs are hotplugged out, due to per-cpu data
being improperly initialised.
(1) The amount of information needed for CPPC performance control in its
cpufreq driver depends on the domain (PSD) coordination type:
ANY: One set of CPPC control and capability data (e.g desired
performance, highest/lowest performance, etc) applies to all
CPUs in the domain.
ALL: Same as ANY. To be noted that this type is not currently
supported. When supported, information about which CPUs
belong to a domain is needed in order for frequency change
requests to be sent to each of them.
HW: It's necessary to store CPPC control and capability
information for all the CPUs. HW will then coordinate the
performance state based on their limitations and requests.
NONE: Same as HW. No HW coordination is expected.
Despite this, the previous initialisation code would indiscriminately
allocate memory for all CPUs (all_cpu_data) and unnecessarily
duplicate performance capabilities and the domain sharing mask and type
for each possible CPU.
(2) With the current per-cpu structure, when having ANY coordination,
the cppc_cpudata cpu information is not initialised (will remain 0)
for all CPUs in a policy, other than policy->cpu. When policy->cpu is
hotplugged out, the driver will incorrectly use the uninitialised (0)
value of the other CPUs when making frequency changes. Additionally,
the previous values stored in the perf_ctrls.desired_perf will be
lost when policy->cpu changes.
Therefore replace the array of per cpu data with a list. The memory for
each structure is allocated at policy init, where a single structure
can be allocated per policy, not per cpu. In order to accommodate the
struct list_head node in the cppc_cpudata structure, the now unused cpu
and cur_policy variables are removed.
For example, on a arm64 Juno platform with 6 CPUs: (0, 1, 2, 3) in PSD1,
(4, 5) in PSD2 - ANY coordination, the memory allocation comparison shows:
Before patch:
- ANY coordination:
total slack req alloc/free caller
0 0 0 0/1 _kernel_size_le_hi32+0x0xffff800008ff7810
0 0 0 0/6 _kernel_size_le_hi32+0x0xffff800008ff7808
128 80 48 1/0 _kernel_size_le_hi32+0x0xffff800008ffc070
768 0 768 6/0 _kernel_size_le_hi32+0x0xffff800008ffc0e4
After patch:
- ANY coordination:
total slack req alloc/free caller
256 0 256 2/0 _kernel_size_le_hi32+0x0xffff800008fed410
0 0 0 0/2 _kernel_size_le_hi32+0x0xffff800008fed274
Additional notes:
- A pointer to the policy's cppc_cpudata is stored in policy->driver_data
- Driver registration is skipped if _CPC entries are not present.
Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
Tested-by: Mian Yousaf Kaukab <ykaukab@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>