kernel.git/drivers/cpufreq/cppc_cpufreq.c, branch linux-5.12.y

cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_init

2021-07-20T14:02:28Z

[ Upstream commit fe2535a44904a77615a3af8e8fd7dafb98fb0e1b ] It's a classic example of memleak, we allocate something, we fail and never free the resources. Make sure we free all resources on policy ->init() failures. Fixes: a28b2bfc099c ("cppc_cpufreq: replace per-cpu data array with a list") Tested-by: Vincent Guittot Reviewed-by: Ionela Voinescu Tested-by: Qian Cai Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin

cppc_cpufreq: replace per-cpu data array with a list

2020-12-15T18:19:32Z

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 Tested-by: Mian Yousaf Kaukab Signed-off-by: Rafael J. Wysocki

cppc_cpufreq: expose information on frequency domains

2020-12-15T18:19:32Z

Use the existing sysfs attribute "freqdomain_cpus" to expose information to userspace about CPUs in the same frequency domain. Signed-off-by: Ionela Voinescu Acked-by: Viresh Kumar Tested-by: Mian Yousaf Kaukab Signed-off-by: Rafael J. Wysocki

cppc_cpufreq: clarify support for coordination types

2020-12-15T18:19:32Z

The previous coordination type handling in the cppc_cpufreq init code created some confusion: the comment mentioned "Support only SW_ANY for now" while only the SW_ALL/ALL case resulted in a failure. The other coordination types (HW_ALL/HW, NONE) were silently supported. Clarify support for coordination types while describing in comments the intended behavior. Signed-off-by: Ionela Voinescu Acked-by: Viresh Kumar Tested-by: Mian Yousaf Kaukab Signed-off-by: Rafael J. Wysocki

cppc_cpufreq: use policy->cpu as driver of frequency setting

2020-12-15T18:19:31Z

Considering only the currently supported coordination types (ANY, HW, NONE), this change only makes a difference for the ANY type, when policy->cpu is hotplugged out. In that case the new policy->cpu will be different from ((struct cppc_cpudata *)policy->driver_data)->cpu. While in this case the controls of *ANY* CPU could be used to drive frequency changes, it's more consistent to use policy->cpu as the leading CPU, as used in all other cppc_cpufreq functions. Additionally, the debug prints in cppc_set_perf() would no longer create confusion when referring to a CPU that is hotplugged out. Signed-off-by: Ionela Voinescu Acked-by: Viresh Kumar Tested-by: Mian Yousaf Kaukab Signed-off-by: Rafael J. Wysocki

cppc_cpufreq: simplify use of performance capabilities

2020-11-17T14:57:09Z

The CPPC performance capabilities are used significantly throughout the driver. Simplify the use of them by introducing a local pointer "caps" to point to cpu_data->perf_caps, in functions that access performance capabilities often. Signed-off-by: Ionela Voinescu Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cppc_cpufreq: clean up cpu, cpu_num and cpunum variable use

2020-11-17T14:57:09Z

In order to maintain the typical naming convention in the cpufreq framework: - replace the use of "cpu" variable name for cppc_cpudata pointers with "cpu_data" - replace variable names "cpu_num" and "cpunum" with "cpu" - make cpu variables unsigned int Where pertinent, also move the initialisation of cpu_data variable to its declaration and make consistent use of the local "cpu" variable. Signed-off-by: Ionela Voinescu Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cppc_cpufreq: fix misspelling, code style and readability issues

2020-11-17T14:57:09Z

Fix a few trivial issues in the cppc_cpufreq driver: - indentation of function arguments - consistent use of tabs (vs space) in defines - spelling: s/Offest/Offset, s/trasition/transition - order of local variables, from long pointers to structures to short ret and i (index) variables, to improve readability Signed-off-by: Ionela Voinescu Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: CPPC: Reuse caps variable in few routines

2020-07-30T05:27:47Z

The 'caps' variable has been defined in cppc_cpufreq_khz_to_perf() and cppc_cpufreq_perf_to_khz() routines, so there is no need to get 'highest_perf' value through 'cpu->caps.highest_perf', we can use 'caps->highest_perf' instead. Signed-off-by: Xin Hao [ Viresh: Updated commit log ] Signed-off-by: Viresh Kumar

cpufreq: cppc: Reorder code and remove apply_hisi_workaround variable

2020-07-30T05:27:46Z

With the current approach we have an extra check in the cppc_cpufreq_get_rate() callback, which checks if hisilicon's get rate implementation should be used instead. While it works fine, the approach isn't very straight forward, over that we have an extra check in the routine. Rearrange code and update the cpufreq driver's get() callback pointer directly for the hisilicon case. This gets the extra variable is removed and the extra check isn't required anymore as well. Tested-by: Xiongfeng Wang Signed-off-by: Viresh Kumar