aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-12-15cpufreq: intel_pstate: Implement the ->adjust_perf() callbackRafael J. Wysocki1-12/+58
Make intel_pstate expose the ->adjust_perf() callback when it operates in the passive mode with HWP enabled which causes the schedutil governor to use that callback instead of ->fast_switch(). The minimum and target performance-level values passed by the governor to ->adjust_perf() are converted to HWP.REQ.MIN and HWP.REQ.DESIRED, respectively, which allows the processor to adjust its configuration to maximize energy-efficiency while providing sufficient capacity. Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> Acked-by: Viresh Kumar <[email protected]>
2020-12-15cpufreq: Add special-purpose fast-switching callback for driversRafael J. Wysocki4-10/+117
First off, some cpufreq drivers (eg. intel_pstate) can pass hints beyond the current target frequency to the hardware and there are no provisions for doing that in the cpufreq framework. In particular, today the driver has to assume that it should not allow the frequency to fall below the one requested by the governor (or the required capacity may not be provided) which may not be the case and which may lead to excessive energy usage in some scenarios. Second, the hints passed by these drivers to the hardware need not be in terms of the frequency, so representing the utilization numbers coming from the scheduler as frequency before passing them to those drivers is not really useful. Address the two points above by adding a special-purpose replacement for the ->fast_switch callback, called ->adjust_perf, allowing the governor to pass abstract performance level (rather than frequency) values for the minimum (required) and target (desired) performance along with the CPU capacity to compare them to. Also update the schedutil governor to use the new callback instead of ->fast_switch if present and if the utilization mertics are frequency-invariant (that is requisite for the direct mapping between the utilization and the CPU performance levels to be a reasonable approximation). Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Viresh Kumar <[email protected]>
2020-12-15cpufreq: schedutil: Add util to struct sg_cpuRafael J. Wysocki1-22/+20
Instead of passing util and max between functions while computing the utilization and capacity, store the former in struct sg_cpu (along with the latter and bw_dl). This will allow the current utilization value to be compared with the one obtained previously (which is requisite for some code changes to follow this one), but also it causes the code to look slightly more consistent and cleaner. Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Viresh Kumar <[email protected]>
2020-12-15cppc_cpufreq: replace per-cpu data array with a listIonela Voinescu3-167/+154
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 <[email protected]> Tested-by: Mian Yousaf Kaukab <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-12-15cppc_cpufreq: expose information on frequency domainsIonela Voinescu2-1/+16
Use the existing sysfs attribute "freqdomain_cpus" to expose information to userspace about CPUs in the same frequency domain. Signed-off-by: Ionela Voinescu <[email protected]> Acked-by: Viresh Kumar <[email protected]> Tested-by: Mian Yousaf Kaukab <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-12-15cppc_cpufreq: clarify support for coordination typesIonela Voinescu1-7/+12
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 <[email protected]> Acked-by: Viresh Kumar <[email protected]> Tested-by: Mian Yousaf Kaukab <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-12-15cppc_cpufreq: use policy->cpu as driver of frequency settingIonela Voinescu1-2/+3
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 <[email protected]> Acked-by: Viresh Kumar <[email protected]> Tested-by: Mian Yousaf Kaukab <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-12-15Merge branch 'acpi-processor' to satisfy dependenciesRafael J. Wysocki2-3/+2
2020-12-15ACPI: processor: fix NONE coordination for domain mapping failureIonela Voinescu2-2/+2
For errors parsing the _PSD domains, a separate domain is returned for each CPU in the failed _PSD domain with no coordination (as per previous comment). But contrary to the intention, the code was setting CPUFREQ_SHARED_TYPE_ALL as coordination type. Change shared_type to CPUFREQ_SHARED_TYPE_NONE in case of errors parsing the domain information. The function still returns the error and the caller is free to bail out the domain initialisation altogether in that case. Given that both functions return domains with a single CPU, this change does not affect the functionality, but clarifies the intention. Signed-off-by: Ionela Voinescu <[email protected]> Acked-by: Viresh Kumar <[email protected]> [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-12-14Merge branch 'cpufreq/arm/linux-next' of ↵Rafael J. Wysocki19-92/+190
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull ARM cpufreq updates for 5.11-rc1 from Viresh Kumar: "This contains the following updates: - Fix imx's NVMEM_IMX_OCOTP dependency (Arnd Bergmann). - Add support for mt8167 and blacklist mt8516 (Fabien Parent). - Some ->get() callback related cleanups to the tegra194 driver and some optimizations in tegra186 driver (Jon Hunter and Sumit Gupta). - Power scale improvements to arm_scmi driver (Lukasz Luba). - Add missing MODULE_DEVICE_TABLE and MODULE_ALIAS to several drivers (Pali Rohár). - Fix error path in mediatek driver (Qinglang Miao). - Fix memleak in ST's cpufreq driver (Yangtao Li)." * 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: (22 commits) cpufreq: arm_scmi: Discover the power scale in performance protocol firmware: arm_scmi: Add power_scale_mw_get() interface cpufreq: tegra194: Rename tegra194_get_speed_common function cpufreq: tegra194: Remove unnecessary frequency calculation cpufreq: tegra186: Simplify cluster information lookup cpufreq: tegra186: Fix sparse 'incorrect type in assignment' warning cpufreq: imx: fix NVMEM_IMX_OCOTP dependency cpufreq: vexpress-spc: Add missing MODULE_ALIAS cpufreq: scpi: Add missing MODULE_ALIAS cpufreq: loongson1: Add missing MODULE_ALIAS cpufreq: sun50i: Add missing MODULE_DEVICE_TABLE cpufreq: st: Add missing MODULE_DEVICE_TABLE cpufreq: qcom: Add missing MODULE_DEVICE_TABLE cpufreq: mediatek: Add missing MODULE_DEVICE_TABLE cpufreq: highbank: Add missing MODULE_DEVICE_TABLE cpufreq: ap806: Add missing MODULE_DEVICE_TABLE cpufreq: mediatek: add missing platform_driver_unregister() on error in mtk_cpufreq_driver_init cpufreq: tegra194: get consistent cpuinfo_cur_freq cpufreq: blacklist mt8516 in cpufreq-dt-platdev cpufreq: mediatek: Add support for mt8167 ...
2020-12-11cpufreq: Fix cpufreq_online() return value on errorsWang ShaoBo1-1/+4
Make cpufreq_online() return negative error codes on all errors that cause the policy to be destroyed, as appropriate. Signed-off-by: Wang ShaoBo <[email protected]> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-12-11cpufreq: Fix up several kerneldoc commentsRafael J. Wysocki1-35/+35
Fix up the remaining kerneldoc comments that don't adhere to the expected format and clarify some of them a bit. No functional changes. Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Viresh Kumar <[email protected]>
2020-12-11cpufreq: stats: Use local_clock() instead of jiffiesViresh Kumar1-8/+8
local_clock() has better precision and accuracy as compared to jiffies, lets use it for time management in cpufreq stats. Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-12-11cpufreq: schedutil: Simplify sugov_update_next_freq()Rafael J. Wysocki1-5/+3
Rearrange a conditional to make it more straightforward. Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Viresh Kumar <[email protected]>
2020-12-11cpufreq: intel_pstate: Simplify intel_cpufreq_update_pstate()Rafael J. Wysocki1-5/+4
Avoid doing the same assignment in both branches of a conditional, do it after the whole conditional instead. Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-12-11Merge back cpufreq material for v5.11.Rafael J. Wysocki3-91/+87
2020-12-08Merge branch 'cpufreq/scmi' into cpufreq/arm/linux-nextViresh Kumar1275-33625/+11753
2020-12-08cpufreq: arm_scmi: Discover the power scale in performance protocolLukasz Luba1-1/+3
Add mechanism to discover the power scale present in the performance protocol for all domains. Provide this information to Energy Model, which then can be checked in other frameworks, e.g. thermal. Suggested-by: Morten Rasmussen <[email protected]> Signed-off-by: Lukasz Luba <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-12-08firmware: arm_scmi: Add power_scale_mw_get() interfaceLukasz Luba2-0/+9
Add a new interface to the existing perf_ops and export the information about the power values scale. This would be used by the cpufreq driver and Energy Model framework to set the performance domains scale: milli-Watts or abstract scale. Suggested-by: Morten Rasmussen <[email protected]> Reviewed-by: Cristian Marussi <[email protected]> Signed-off-by: Lukasz Luba <[email protected]> Acked-by: Sudeep Holla <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: tegra194: Rename tegra194_get_speed_common functionJon Hunter1-2/+2
The function tegra194_get_speed_common() uses hardware timers to calculate the current CPUFREQ and so rename this function to be tegra194_calculate_speed() to reflect what it does. Signed-off-by: Jon Hunter <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: tegra194: Remove unnecessary frequency calculationJon Hunter1-9/+3
The Tegra194 CPUFREQ driver sets the CPUFREQ_NEED_INITIAL_FREQ_CHECK flag which means that the CPUFREQ framework will call the 'get' callback on boot to determine the current frequency of the CPUs. Therefore, it is not necessary for the Tegra194 CPUFREQ driver to internally call the tegra194_get_speed_common() during initialisation to query the current frequency as well. Fix this by removing the call to the tegra194_get_speed_common() during initialisation and simplify the code. Signed-off-by: Jon Hunter <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: tegra186: Simplify cluster information lookupJon Hunter1-65/+20
The CPUFREQ driver framework references each individual CPUs when getting and setting the speed. Tegra186 has 3 clusters of A57 CPUs and 1 cluster of Denver CPUs. Hence, the Tegra186 CPUFREQ driver need to know which cluster a given CPU belongs to. The logic in the Tegra186 driver can be greatly simplified by storing the cluster ID associated with each CPU in the tegra186_cpufreq_cpu structure. This allow us to completely remove the Tegra cluster info structure from the driver and simplifiy the code. Signed-off-by: Jon Hunter <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: tegra186: Fix sparse 'incorrect type in assignment' warningJon Hunter1-15/+46
Sparse warns that the incorrect type is being assigned to the CPUFREQ driver_data variable in the Tegra186 CPUFREQ driver. The Tegra186 CPUFREQ driver is assigned a type of 'void __iomem *' to a pointer of type 'void *' ... drivers/cpufreq/tegra186-cpufreq.c:72:37: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *driver_data @@ got void [noderef] __iomem * @@ ... drivers/cpufreq/tegra186-cpufreq.c:87:40: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected void [noderef] __iomem *edvd_reg @@ got void *driver_data @@ The Tegra186 CPUFREQ driver is using the policy->driver_data variable to store and iomem pointer to a Tegra186 CPU register that is used to set the clock speed for the CPU. This is not necessary because the register base address is already stored in the driver data and the offset of the register for each CPU is static. Therefore, fix this by adding a new structure with the register offsets for each CPU and store this in the main driver data structure along with the register base address. Please note that a new structure has been added for storing the register offsets rather than a simple array, because this will permit further clean-ups and simplification of the driver. Signed-off-by: Jon Hunter <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: imx: fix NVMEM_IMX_OCOTP dependencyArnd Bergmann1-1/+1
A driver should not 'select' drivers from another subsystem. If NVMEM is disabled, this one results in a warning: WARNING: unmet direct dependencies detected for NVMEM_IMX_OCOTP Depends on [n]: NVMEM [=n] && (ARCH_MXC [=y] || COMPILE_TEST [=y]) && HAS_IOMEM [=y] Selected by [y]: - ARM_IMX6Q_CPUFREQ [=y] && CPU_FREQ [=y] && (ARM || ARM64 [=y]) && ARCH_MXC [=y] && REGULATOR_ANATOP [=y] Change the 'select' to 'depends on' to prevent it from going wrong, and allow compile-testing without that driver, since it is only a runtime dependency. Fixes: 2782ef34ed23 ("cpufreq: imx: Select NVMEM_IMX_OCOTP") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: vexpress-spc: Add missing MODULE_ALIASPali Rohár1-0/+1
This patch adds missing MODULE_ALIAS for automatic loading of this cpufreq driver when it is compiled as an external module. Signed-off-by: Pali Rohár <[email protected]> Fixes: 47ac9aa165540 ("cpufreq: arm_big_little: add vexpress SPC interface driver") Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: scpi: Add missing MODULE_ALIASPali Rohár1-0/+1
This patch adds missing MODULE_ALIAS for automatic loading of this cpufreq driver when it is compiled as an external module. Signed-off-by: Pali Rohár <[email protected]> Fixes: 8def31034d033 ("cpufreq: arm_big_little: add SCPI interface driver") Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: loongson1: Add missing MODULE_ALIASPali Rohár1-0/+1
This patch adds missing MODULE_ALIAS for automatic loading of this cpufreq driver when it is compiled as an external module. Signed-off-by: Pali Rohár <[email protected]> Fixes: a0a22cf14472f ("cpufreq: Loongson1: Add cpufreq driver for Loongson1B") Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: sun50i: Add missing MODULE_DEVICE_TABLEPali Rohár1-0/+1
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this cpufreq driver when it is compiled as an external module. Signed-off-by: Pali Rohár <[email protected]> Fixes: f328584f7bff8 ("cpufreq: Add sun50i nvmem based CPU scaling driver") Reviewed-by: Yangtao Li <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: st: Add missing MODULE_DEVICE_TABLEPali Rohár1-0/+7
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this cpufreq driver when it is compiled as an external module. Signed-off-by: Pali Rohár <[email protected]> Fixes: ab0ea257fc58d ("cpufreq: st: Provide runtime initialised driver for ST's platforms") Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: qcom: Add missing MODULE_DEVICE_TABLEPali Rohár1-0/+1
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this cpufreq driver when it is compiled as an external module. Signed-off-by: Pali Rohár <[email protected]> Fixes: 46e2856b8e188 ("cpufreq: Add Kryo CPU scaling driver") Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: mediatek: Add missing MODULE_DEVICE_TABLEPali Rohár1-0/+1
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this cpufreq driver when it is compiled as an external module. Signed-off-by: Pali Rohár <[email protected]> Fixes: 501c574f4e3a5 ("cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC") Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: highbank: Add missing MODULE_DEVICE_TABLEPali Rohár1-0/+7
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this cpufreq driver when it is compiled as an external module. Signed-off-by: Pali Rohár <[email protected]> Fixes: 6754f556103be ("cpufreq / highbank: add support for highbank cpufreq") Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: ap806: Add missing MODULE_DEVICE_TABLEPali Rohár1-0/+6
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this cpufreq driver when it is compiled as an external module. Signed-off-by: Pali Rohár <[email protected]> Fixes: f525a670533d9 ("cpufreq: ap806: add cpufreq driver for Armada 8K") Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: mediatek: add missing platform_driver_unregister() on error in ↵Qinglang Miao1-0/+1
mtk_cpufreq_driver_init Add the missing platform_driver_unregister() before return from mtk_cpufreq_driver_init in the error handling case when failed to register mtk-cpufreq platform device Signed-off-by: Qinglang Miao <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: tegra194: get consistent cpuinfo_cur_freqSumit Gupta1-9/+53
Frequency returned by 'cpuinfo_cur_freq' using counters is not fixed and keeps changing slightly. This change returns a consistent value from freq_table. If the reconstructed frequency has acceptable delta from the last written value, then return the frequency corresponding to the last written ndiv value from freq_table. Otherwise, print a warning and return the reconstructed freq. Signed-off-by: Sumit Gupta <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: blacklist mt8516 in cpufreq-dt-platdevFabien Parent1-0/+1
Add MT8516 to cpufreq-dt-platdev blacklist since the actual scaling is handled by the 'mediatek-cpufreq' driver. Signed-off-by: Fabien Parent <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: mediatek: Add support for mt8167Fabien Parent2-0/+2
Add compatible string for mediatek mt8167 Signed-off-by: Fabien Parent <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-12-07cpufreq: sti-cpufreq: fix mem leak in sti_cpufreq_set_opp_info()Yangtao Li1-1/+6
Use dev_pm_opp_put_prop_name() to avoid mem leak, which free opp_table. Signed-off-by: Yangtao Li <[email protected]> Signed-off-by: Yangtao Li <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-11-25ACPI: processor: Drop duplicate setting of shared_cpu_mapPunit Agrawal1-1/+0
'shared_cpu_map', stored as part of the per-processor acpi_processor_performance structre, is used to store CPUs that share a performance domain. By definition it contains the owning CPU. While building the 'shared_cpu_map' it is being set twice - once while initialising the performance domains and again when matching CPUs belonging to the same domain. Drop the unnecessary initialisation. Signed-off-by: Punit Agrawal <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-11-23Merge branch 'cpufreq/arm/fixes' of ↵Rafael J. Wysocki1-1/+3
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull SCMI cpufreq driver fix for 5.10-rc6 from Viresh Kumar: "This fixes a build issues with SCMI cpufreq driver in the !CONFIG_COMMON_CLK case." * 'cpufreq/arm/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: scmi: Fix build for !CONFIG_COMMON_CLK
2020-11-23cpufreq: scmi: Fix build for !CONFIG_COMMON_CLKSudeep Holla1-1/+3
Commit 8410e7f3b31e ("cpufreq: scmi: Fix OPP addition failure with a dummy clock provider") registers a dummy clock provider using devm_of_clk_add_hw_provider. These *_hw_provider functions are defined only when CONFIG_COMMON_CLK=y. One possible fix is to add the Kconfig dependency, but since we plan to move away from the clock dependency for scmi cpufreq, it is preferrable to avoid that. Let us just conditionally compile out the offending call to devm_of_clk_add_hw_provider. It also uses the variable 'dev' outside of the #ifdef block to avoid build warning. Fixes: 8410e7f3b31e ("cpufreq: scmi: Fix OPP addition failure with a dummy clock provider") Cc: Rafael J. Wysocki <[email protected]> Cc: Viresh Kumar <[email protected]> Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2020-11-22Linux 5.10-rc5Linus Torvalds1-1/+1
2020-11-22Merge branch 'for-linus' of ↵Linus Torvalds12-17/+223
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Jiri Kosina: - Various functionality / regression fixes for Logitech devices from Hans de Goede - Fix for (recently added) GPIO support in mcp2221 driver from Lars Povlsen - Power management handling fix/quirk in i2c-hid driver for certain BIOSes that have strange aproach to power-cycle from Hans de Goede - a few device ID additions and device-specific quirks * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: logitech-dj: Fix Dinovo Mini when paired with a MX5x00 receiver HID: logitech-dj: Fix an error in mse_bluetooth_descriptor HID: Add Logitech Dinovo Edge battery quirk HID: logitech-hidpp: Add HIDPP_CONSUMER_VENDOR_KEYS quirk for the Dinovo Edge HID: logitech-dj: Handle quad/bluetooth keyboards with a builtin trackpad HID: add HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE for Gamevice devices HID: mcp2221: Fix GPIO output handling HID: hid-sensor-hub: Fix issue with devices with no report ID HID: i2c-hid: Put ACPI enumerated devices in D3 on shutdown HID: add support for Sega Saturn HID: cypress: Support Varmilo Keyboards' media hotkeys HID: ite: Replace ABS_MISC 120/121 events with touchpad on/off keypresses HID: logitech-hidpp: Add PID for MX Anywhere 2 HID: uclogic: Add ID for Trust Flex Design Tablet
2020-11-22Merge tag 'sched-urgent-2020-11-22' of ↵Linus Torvalds4-57/+95
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Thomas Gleixner: "A couple of scheduler fixes: - Make the conditional update of the overutilized state work correctly by caching the relevant flags state before overwriting them and checking them afterwards. - Fix a data race in the wakeup path which caused loadavg on ARM64 platforms to become a random number generator. - Fix the ordering of the iowaiter accounting operations so it can't be decremented before it is incremented. - Fix a bug in the deadline scheduler vs. priority inheritance when a non-deadline task A has inherited the parameters of a deadline task B and then blocks on a non-deadline task C. The second inheritance step used the static deadline parameters of task A, which are usually 0, instead of further propagating task B's parameters. The zero initialized parameters trigger a bug in the deadline scheduler" * tag 'sched-urgent-2020-11-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/deadline: Fix priority inheritance with multiple scheduling classes sched: Fix rq->nr_iowait ordering sched: Fix data-race in wakeup sched/fair: Fix overutilized update in enqueue_task_fair()
2020-11-22Merge tag 'perf-urgent-2020-11-22' of ↵Linus Torvalds4-24/+12
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fix from Thomas Gleixner: "A single fix for the x86 perf sysfs interfaces which used kobject attributes instead of device attributes and therefore making clang's control flow integrity checker upset" * tag 'perf-urgent-2020-11-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86: fix sysfs type mismatches
2020-11-22Merge tag 'locking-urgent-2020-11-22' of ↵Linus Torvalds1-2/+4
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fix from Thomas Gleixner: "A single fix for lockdep which makes the recursion protection cover graph lock/unlock" * tag 'locking-urgent-2020-11-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: lockdep: Put graph lock/unlock under lock_recursion protection
2020-11-22Merge tag 'efi-urgent-for-v5.10-rc3' of ↵Linus Torvalds3-11/+17
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI fixes from Borislav Petkov: "Forwarded EFI fixes from Ard Biesheuvel: - fix memory leak in efivarfs driver - fix HYP mode issue in 32-bit ARM version of the EFI stub when built in Thumb2 mode - avoid leaking EFI pgd pages on allocation failure" * tag 'efi-urgent-for-v5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/x86: Free efi_pgd with free_pages() efivarfs: fix memory leak in efivarfs_create() efi/arm: set HSCTLR Thumb2 bit correctly for HVC calls from HYP
2020-11-22Merge tag 'x86_urgent_for_v5.10-rc5' of ↵Linus Torvalds2-57/+29
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - An IOMMU VT-d build fix when CONFIG_PCI_ATS=n along with a revert of same because the proper one is going through the IOMMU tree (Thomas Gleixner) - An Intel microcode loader fix to save the correct microcode patch to apply during resume (Chen Yu) - A fix to not access user memory of other processes when dumping opcode bytes (Thomas Gleixner) * tag 'x86_urgent_for_v5.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: Revert "iommu/vt-d: Take CONFIG_PCI_ATS into account" x86/dumpstack: Do not try to access user space code of other tasks x86/microcode/intel: Check patch signature before saving microcode for early loading iommu/vt-d: Take CONFIG_PCI_ATS into account
2020-11-22Merge branch 'akpm' (patches from Andrew)Linus Torvalds16-49/+75
Merge misc fixes from Andrew Morton: "8 patches. Subsystems affected by this patch series: mm (madvise, pagemap, readahead, memcg, userfaultfd), kbuild, and vfs" * emailed patches from Andrew Morton <[email protected]>: mm: fix madvise WILLNEED performance problem libfs: fix error cast of negative value in simple_attr_write() mm/userfaultfd: do not access vma->vm_mm after calling handle_userfault() mm: memcg/slab: fix root memcg vmstats mm: fix readahead_page_batch for retry entries mm: fix phys_to_target_node() and memory_add_physaddr_to_nid() exports compiler-clang: remove version check for BPF Tracing mm/madvise: fix memory leak from process_madvise
2020-11-22Merge tag 'staging-5.10-rc5' of ↵Linus Torvalds13-85/+165
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging and IIO fixes from Greg KH: "Here are some small Staging and IIO driver fixes for 5.10-rc5. They include: - IIO fixes for reported regressions and problems - new device ids for IIO drivers - new device id for rtl8723bs driver - staging ralink driver Kconfig dependency fix - staging mt7621-pci bus resource fix All of these have been in linux-next all week with no reported issues" * tag 'staging-5.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: iio: accel: kxcjk1013: Add support for KIOX010A ACPI DSM for setting tablet-mode iio: accel: kxcjk1013: Replace is_smo8500_device with an acpi_type enum docs: ABI: testing: iio: stm32: remove re-introduced unsupported ABI iio: light: fix kconfig dependency bug for VCNL4035 iio/adc: ingenic: Fix AUX/VBAT readings when touchscreen is used iio/adc: ingenic: Fix battery VREF for JZ4770 SoC staging: rtl8723bs: Add 024c:0627 to the list of SDIO device-ids staging: ralink-gdma: fix kconfig dependency bug for DMA_RALINK staging: mt7621-pci: avoid to request pci bus resources iio: imu: st_lsm6dsx: set 10ms as min shub slave timeout counter/ti-eqep: Fix regmap max_register iio: adc: stm32-adc: fix a regression when using dma and irq iio: adc: mediatek: fix unset field iio: cros_ec: Use default frequencies when EC returns invalid information