summaryrefslogtreecommitdiff
path: root/drivers/cpufreq
AgeCommit message (Collapse)Author
2015-02-03cpufreq: Create for_each_policy()Viresh Kumar
To make code more readable and less error prone, lets create a helper macro for iterating over all active policies. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-03cpufreq: Drop cpufreq_disabled() check from cpufreq_cpu_{get|put}()Viresh Kumar
When cpufreq is disabled, the per-cpu variable would have been set to NULL. Remove this unnecessary check. [ Changelog from Saravana Kannan. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Saravana Kannan <skannan@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-03cpufreq: Set cpufreq_cpu_data to NULL before putting kobjectViresh Kumar
In __cpufreq_remove_dev_finish(), per-cpu 'cpufreq_cpu_data' needs to be cleared before calling kobject_put(&policy->kobj) and under cpufreq_driver_lock. Otherwise, if someone else calls cpufreq_cpu_get() in parallel with it, they can obtain a non-NULL policy from that after kobject_put(&policy->kobj) was executed. Consider this case: Thread A Thread B cpufreq_cpu_get() acquire cpufreq_driver_lock read-per-cpu cpufreq_cpu_data kobject_put(&policy->kobj); kobject_get(&policy->kobj); ... per_cpu(&cpufreq_cpu_data, cpu) = NULL And this will result in a warning like this one: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 4 at include/linux/kref.h:47 kobject_get+0x41/0x50() Modules linked in: acpi_cpufreq(+) nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c sd_mod ixgbe igb mdio ahci hwmon ... Call Trace: [<ffffffff81661b14>] dump_stack+0x46/0x58 [<ffffffff81072b61>] warn_slowpath_common+0x81/0xa0 [<ffffffff81072c7a>] warn_slowpath_null+0x1a/0x20 [<ffffffff812e16d1>] kobject_get+0x41/0x50 [<ffffffff815262a5>] cpufreq_cpu_get+0x75/0xc0 [<ffffffff81527c3e>] cpufreq_update_policy+0x2e/0x1f0 [<ffffffff810b8cb2>] ? up+0x32/0x50 [<ffffffff81381aa9>] ? acpi_ns_get_node+0xcb/0xf2 [<ffffffff81381efd>] ? acpi_evaluate_object+0x22c/0x252 [<ffffffff813824f6>] ? acpi_get_handle+0x95/0xc0 [<ffffffff81360967>] ? acpi_has_method+0x25/0x40 [<ffffffff81391e08>] acpi_processor_ppc_has_changed+0x77/0x82 [<ffffffff81089566>] ? move_linked_works+0x66/0x90 [<ffffffff8138e8ed>] acpi_processor_notify+0x58/0xe7 [<ffffffff8137410c>] acpi_ev_notify_dispatch+0x44/0x5c [<ffffffff8135f293>] acpi_os_execute_deferred+0x15/0x22 [<ffffffff8108c910>] process_one_work+0x160/0x410 [<ffffffff8108d05b>] worker_thread+0x11b/0x520 [<ffffffff8108cf40>] ? rescuer_thread+0x380/0x380 [<ffffffff81092421>] kthread+0xe1/0x100 [<ffffffff81092340>] ? kthread_create_on_node+0x1b0/0x1b0 [<ffffffff81669ebc>] ret_from_fork+0x7c/0xb0 [<ffffffff81092340>] ? kthread_create_on_node+0x1b0/0x1b0 ---[ end trace 89e66eb9795efdf7 ]--- The actual code flow is as follows: Thread A: Workqueue: kacpi_notify acpi_processor_notify() acpi_processor_ppc_has_changed() cpufreq_update_policy() cpufreq_cpu_get() kobject_get() Thread B: xenbus_thread() xenbus_thread() msg->u.watch.handle->callback() handle_vcpu_hotplug_event() vcpu_hotplug() cpu_down() __cpu_notify(CPU_POST_DEAD..) cpufreq_cpu_callback() __cpufreq_remove_dev_finish() cpufreq_policy_put_kobj() kobject_put() cpufreq_cpu_get() gets the policy from per-cpu variable cpufreq_cpu_data under cpufreq_driver_lock, and once it gets a valid policy it expects it to not be freed until cpufreq_cpu_put() is called. But the race happens when another thread puts the kobject first and updates cpufreq_cpu_data before or later. And so the first thread gets a valid policy structure and before it does kobject_get() on it, the second one has already done kobject_put(). Fix this by setting cpufreq_cpu_data to NULL before putting the kobject and that too under locks. Reported-by: Ethan Zhao <ethan.zhao@oracle.com> Reported-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 3.12+ <stable@vger.kernel.org> # 3.12+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-02Merge branch 'clk-next' into v3.19-rc7Michael Turquette
2015-01-31cpufreq: exynos: allow modular buildArnd Bergmann
The exynos cpufreq driver code recently gained a dependency on the cooling code, which may be a loadable module. This breaks an ARM allmodconfig build: drivers/built-in.o: In function `exynos_cpufreq_probe': :(.text+0x1748e8): undefined reference to `of_cpufreq_cooling_register' To avoid this problem, change cpufreq Kconfig to allow the drivers to be loadable modules as well and enforce a dependency on the thermal module. This change, in order to allow module builds on this cpufreq driver, properly constructs the driver into a single module, instead of several modules. The change also keeps the proper platform dependency, and therefore, it wont load in platforms that are not supposed to be loaded. The user will be able to build the support for all platforms, or select which platforms (s)he wants (as originally), except that now it can be a module, instead. Besides, it will still keep the driver only on those configs that expect it to be on. And it won't compile/load on platforms that it is not supposed to. It brings the config ARM_EXYNOS_CPU_FREQ_BOOST_SW closer to this driver, so it looks better in the menuconfig. We intentionally change ARM_EXYNOS5440_CPUFREQ to be tristate too, to avoid future troubles. Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Kukjin Kim <kgene@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-pm@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Fixes: e725d26c4857 ("cpufreq: exynos: Use device tree to determine if cpufreq cooling should be registered") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2015-01-30intel_pstate: honor user space min_perf_pct override on resumeKristen Carlson Accardi
If the user has requested an override of the min_perf_pct via sysfs, then it should be restored whenever policy is updated, such as on resume. Take the max of whatever the user requested and whatever the policy is. Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-30intel_pstate: respect cpufreq policy requestSrinivas Pandruvada
When thermal or other subsystem requests to change the policy, use that irrepective of whether cpufreq policy is PERFORMANCE or not. Without this change, when thermal subsystem passive policy wants to reduce performance, it still runs at 100%. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-30intel_pstate: Add num_pstates to sysfsKristen Carlson Accardi
Add a sysfs interface to display the total number of supported pstates. This value is independent of whether turbo has been enabled or disabled. Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-30intel_pstate: expose turbo range to sysfsKristen Carlson Accardi
This patch adds "turbo_pct" to the intel_pstate sysfs interface. turbo_pct will display the percentage of the total supported pstates that are in the turbo range. This value is independent of whether turbo has been disabled or not. Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-30intel_pstate: Add support for SkyLakeKristen Carlson Accardi
Add SKL cpuid. Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-24cpufreq: exynos: Use device tree to determine if cpufreq cooling should be ↵Lukasz Majewski
registered With thermal subsystem rework it is necessary to tune current cpufreq code to use cpu frequency change as a potential cooling device. Now the cpu cooling device is registered only when proper nodes and properties are available in device tree. Lack of them, however, will not prevent cpufreq for normal operation. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2015-01-23cpufreq: stats: drop unnecessary lockingViresh Kumar
There is no possibility of any race on updating last_index, trans_table or total_trans as these are updated only by cpufreq_stat_notifier_trans() which will be called sequentially. The only place where locking is still relevant is: cpufreq_stats_update(), which updates time_in_state and last_time. This can be called by two thread in parallel, that may result in races. The two threads being: - sysfs read of time_in_state - and frequency transition that calls cpufreq_stat_notifier_trans(). Remove locking from the first case mentioned above. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: stats: don't update stats on false notifiersViresh Kumar
We need to call cpufreq_stats_update() to update 'time_in_state' for the last frequency. This is achieved by calling it from cpufreq_stat_notifier_trans(), which is called after frequency transition. But if we detect that the cpu's frequency haven't really changed and its a false POSTCHANGE notification, we don't really need to update time_in_state. It wouldn't cause any harm in calling cpufreq_stats_update() but we can avoid calling it here and call it when the frequency really changes. The result will be the same but more efficient. Reviewed-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: stats: don't update stats from show_trans_table()Viresh Kumar
cpufreq_stats_update() updates time_in_state and nothing else. It should ideally be updated only in two cases: - User requested for the current value of time_in_state. - We have switched states and so need to update time for the last state. Currently, we are also doing this while user asks for the transition table of frequencies. It wouldn't do any harm, but no good as well. Its useless here. Remove it. Reviewed-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: stats: time_in_state can't be NULL in cpufreq_stats_update()Viresh Kumar
'time_in_state' can't be NULL if 'stats' is valid. These are allocated together and only if time_in_state is allocated successfully, we update policy->stats. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: stats: create sysfs group once we are readyViresh Kumar
Userspace is free to read value of any file from cpufreq/stats directory once they are created. __cpufreq_stats_create_table() is creating the sysfs files first and then allocating resources for them. Though it would be quite difficult to trigger the racy situation here, but for the sake of keeping sensible code lets create sysfs entries only after we are ready to go. This also does some makeup to the routine to make it look better. Reviewed-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: remove CPUFREQ_UPDATE_POLICY_CPU notificationsViresh Kumar
CPUFREQ_UPDATE_POLICY_CPU notifications were used only from cpufreq-stats which doesn't use it anymore. Remove them. This also decrements values of other notification macros defined after CPUFREQ_UPDATE_POLICY_CPU by 1 to remove gaps. Hopefully all users are using macro's instead of direct numbers and so they wouldn't break as macro values are changed now. Reviewed-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: stats: drop 'cpu' field of struct cpufreq_statsViresh Kumar
'cpu' field of struct cpufreq_stats isn't used anymore and so can be dropped. This change makes cpufreq_stats_update_policy_cpu() empty and so that is removed as well. Reviewed-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: Remove (now) unused 'last_cpu' from struct cpufreq_policyViresh Kumar
'last_cpu' was used only from cpufreq-stats and isn't used anymore. Get rid of it. Reviewed-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: stats: rename 'struct cpufreq_stats' objects as 'stats'Viresh Kumar
Currently we name objects of 'struct cpufreq_stats' as 'stat' and 'stats'. Use 'stats' to make it consistent. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: stats: get rid of per-cpu cpufreq_stats_tableViresh Kumar
All CPUs sharing a cpufreq policy share stats too. For this reason, add a stats pointer to struct cpufreq_policy and drop per-CPU variable cpufreq_stats_table used for accessing cpufreq stats so as to reduce code complexity. Reviewed-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: stats: pass 'stat' to cpufreq_stats_update()Viresh Kumar
It is better to pass a struct cpufreq_stats pointer to cpufreq_stats_update() instead of a CPU number, because that's all it needs. Even if we pass a cpu number to cpufreq_stats_update(), it reads the per-cpu variable to get 'stats' out of it. So we are doing these operations unnecessarily: - First getting the cpu number to pass to cpufreq_stats_update(), stat->cpu. - And then getting stats from the cpu, per_cpu(cpufreq_stats_table, cpu). Reviewed-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: stats: don't check for freq table while freeing statsViresh Kumar
While we allocate stats, we do need to check if freq-table is present or not as we need to use it then. But while freeing stats, all we need to know is if stats holds a valid pointer value. There is no use of testing if cpufreq table is present or not. Don't check it. Reviewed-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: stats: initialize 'cur_time' on its definitionViresh Kumar
'cur_time' is defined in the first line and is then assigned a value in the next line. Initialize it while defining it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: stats: remove unused cpufreq_stats_attributeViresh Kumar
It was never used, but is there since the first commit. Remove it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: stats: return -EEXIST when stats are already allocatedViresh Kumar
__cpufreq_stats_create_table() is called from: - cpufreq notifier on creation of a new policy. Stats will always be NULL here. - cpufreq_stats_init() for all CPUs as cpufreq-stats might have been initialized after cpufreq driver. For any policy, 'stats' will be NULL for the first CPU only and will be valid for all other CPUs managed by the same policy. While we return for other CPUs, we don't return the right error value. It's not that we would fail with -EBUSY. But generally, this is what these return values mean: - EBUSY: we are busy right now, try again. And the retry attempt might be immediate. - EEXIST: We already have what you are trying to create and there is no need to create it again, and so no more tries are required. Reviewed-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: stats: Improve module description stringViresh Kumar
The MODULE_DESCRIPTION() string is just too long and then is broken into multiple lines just to make checkpatch happy. Rewrite it to make it more precise. Reviewed-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: move some initialization stuff to cpufreq_policy_alloc()Viresh Kumar
We need to initialize completion and work only on policy allocation and not really on the policy restore side and so we better move this piece of code to cpufreq_policy_alloc(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: check cpufreq_policy_list instead of scanning policies for all CPUsViresh Kumar
CPUFREQ_STICKY flag is set by drivers which don't want to get unregistered even if cpufreq-core isn't able to initialize policy for any CPU. When this flag isn't set, we try to unregister the driver. To find out which CPUs are registered and which are not, we try to check per_cpu cpufreq_cpu_data for all CPUs. Because we have a list of valid policies available now, we better check if the list is empty or not instead of the 'for' loop. That will be much more efficient. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: limit the scope of l_p_j variablesViresh Kumar
These variables are just used within adjust_jiffies() and so must be local to it. Also there is no need of a dummy routine for CONFIG_SMP case as we can take care of all that with help of macros in the same routine. It doesn't look that ugly. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: use light-weight cpufreq_cpu_get_raw() in __cpufreq_add_dev()Viresh Kumar
We just need to check if a 'policy' is already present for the cpu we are adding. We don't need to take all the locks and do kobject usage updates. Use the light-weight cpufreq_cpu_get_raw() routine instead. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: get rid of 'tpolicy' from __cpufreq_add_dev()Viresh Kumar
There is no need of this separate variable, use 'policy' instead. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: get rid of CONFIG_{HOTPLUG_CPU|SMP} messViresh Kumar
These are messing up more than the benefit they provide. It isn't a lot of code anyway, that we will compile without them. Kill them. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: update driver_data->flags only if we are registering driverViresh Kumar
We should first check if a cpufreq driver is already registered or not before updating driver_data->flags. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: pass policy to __cpufreq_get()Viresh Kumar
There is no point finding out the 'policy' again within __cpufreq_get() when all the callers already have it. Just make them pass policy instead. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: pass policy to cpufreq_out_of_syncViresh Kumar
There is no point finding out the 'policy' again within cpufreq_out_of_sync() when all the callers already have it. Just make them pass policy instead. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: No need to check for has_target()Viresh Kumar
Either we can be setpolicy or target type, nothing else. And so the else part of setpolicy will automatically be of has_target() type. And so we don't need to check it again. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: s/__find_governor/find_governorViresh Kumar
Remove unnecessary from find_governor's name. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: merge 'if' blocks in __cpufreq_remove_dev_prepare()Viresh Kumar
There are two 'if' blocks here, checking for !cpufreq_driver->setpolicy and has_target(). Both are actually doing the same thing, merge them. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: don't need line break in show_scaling_cur_freq()Viresh Kumar
No need of an unnecessary line break. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: remove extra parenthesisViresh Kumar
We can live without it and so we should. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: remove dangling commentViresh Kumar
It doesn't make any sense at all and is a leftover of some earlier commit. Remove it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: suspend cpufreq governors on shutdownDoug Anderson
We should stop cpufreq governors when we shut down the system. If we don't do this, we can end up with this deadlock: 1. cpufreq governor may be running on a CPU other than CPU0. 2. In machine_restart() we call smp_send_stop() which stops CPUs. If one of these CPUs was actively running a cpufreq governor then it may have the mutex / spinlock needed to access the main PMIC in the system (perhaps over I2C) 3. If a machine needs access to the main PMIC in order to shutdown then it will never get it since the mutex was lost when the other CPU stopped. 4. We'll hang (possibly eventually hitting the hard lockup detector). Let's avoid the problem by stopping the cpufreq governor at shutdown, which is a sensible thing to do anyway. Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23cpufreq: drop owner assignment from platform_driversWolfram Sang
This platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-21Merge branch 'for-mingo' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu Pull RCU updates from Paul E. McKenney: - Documentation updates. - Miscellaneous fixes. - Preemptible-RCU fixes, including fixing an old bug in the interaction of RCU priority boosting and CPU hotplug. - SRCU updates. - RCU CPU stall-warning updates. - RCU torture-test updates. Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-01-20clk: ppc-corenet: rename driver to clk-qoriqTang Yuantian
Freescale introduced new ARM-based socs which using the compatible clock IP block with PowerPC-based socs'. So this driver can be used on both platforms. Updated relevant descriptions and renamed this driver to better represent its meaning and keep the function of driver untouched. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-06rcu: Make SRCU optional by using CONFIG_SRCUPranith Kumar
SRCU is not necessary to be compiled by default in all cases. For tinification efforts not compiling SRCU unless necessary is desirable. The current patch tries to make compiling SRCU optional by introducing a new Kconfig option CONFIG_SRCU which is selected when any of the components making use of SRCU are selected. If we do not select CONFIG_SRCU, srcu.o will not be compiled at all. text data bss dec hex filename 2007 0 0 2007 7d7 kernel/rcu/srcu.o Size of arch/powerpc/boot/zImage changes from text data bss dec hex filename 831552 64180 23944 919676 e087c arch/powerpc/boot/zImage : before 829504 64180 23952 917636 e0084 arch/powerpc/boot/zImage : after so the savings are about ~2000 bytes. Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com> CC: Josh Triplett <josh@joshtriplett.org> CC: Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> [ paulmck: resolve conflict due to removal of arch/ia64/kvm/Kconfig. ]
2014-12-29Merge branches 'pm-cpufreq' and 'pm-cpuidle'Rafael J. Wysocki
* pm-cpufreq: cpufreq: fix a NULL pointer dereference in __cpufreq_governor() cpufreq-dt: defer probing if OPP table is not ready * pm-cpuidle: cpuidle / ACPI: remove unused CPUIDLE_FLAG_TIME_INVALID cpuidle: ladder: Better idle duration measurement without using CPUIDLE_FLAG_TIME_INVALID cpuidle: menu: Better idle duration measurement without using CPUIDLE_FLAG_TIME_INVALID
2014-12-20cpufreq: Add SFI based cpufreq driver supportSrinidhi Kasagar
This adds the SFI based cpu freq driver for some of the Intel's Silvermont based Atom architectures like Z34xx and Z35xx. Signed-off-by: Rudramuni, Vishwesh M <vishwesh.m.rudramuni@intel.com> Signed-off-by: Srinidhi Kasagar <srinidhi.kasagar@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Len Brown <len.brown@intel.com>
2014-12-19cpufreq: fix a NULL pointer dereference in __cpufreq_governor()Ethan Zhao
If ACPI _PPC changed notification happens before governor was initiated while kernel is booting, a NULL pointer dereference will be triggered: BUG: unable to handle kernel NULL pointer dereference at 0000000000000030 IP: [<ffffffff81470453>] __cpufreq_governor+0x23/0x1e0 PGD 0 Oops: 0000 [#1] SMP ... ... RIP: 0010:[<ffffffff81470453>] [<ffffffff81470453>] __cpufreq_governor+0x23/0x1e0 RSP: 0018:ffff881fcfbcfbb8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff881fd11b3980 RCX: ffff88407fc20000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff881fd11b3980 RBP: ffff881fcfbcfbd8 R08: 0000000000000000 R09: 000000000000000f R10: ffffffff818068d0 R11: 0000000000000043 R12: 0000000000000004 R13: 0000000000000000 R14: ffffffff8196cae0 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff881fffc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000030 CR3: 00000000018ae000 CR4: 00000000000407f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process kworker/0:3 (pid: 750, threadinfo ffff881fcfbce000, task ffff881fcf556400) Stack: ffff881fffc17d00 ffff881fcfbcfc18 ffff881fd11b3980 0000000000000000 ffff881fcfbcfc08 ffffffff81470d08 ffff881fd11b3980 0000000000000007 ffff881fcfbcfc18 ffff881fffc17d00 ffff881fcfbcfd28 ffffffff81472e9a Call Trace: [<ffffffff81470d08>] __cpufreq_set_policy+0x1b8/0x2e0 [<ffffffff81472e9a>] cpufreq_update_policy+0xca/0x150 [<ffffffff81472f20>] ? cpufreq_update_policy+0x150/0x150 [<ffffffff81324a96>] acpi_processor_ppc_has_changed+0x71/0x7b [<ffffffff81320bcd>] acpi_processor_notify+0x55/0x115 [<ffffffff812f9c29>] acpi_device_notify+0x19/0x1b [<ffffffff813084ca>] acpi_ev_notify_dispatch+0x41/0x5f [<ffffffff812f64a4>] acpi_os_execute_deferred+0x27/0x34 The root cause is a race conditon -- cpufreq core and acpi-cpufreq driver were initiated, but cpufreq_governor wasn't and _PPC changed notification happened, __cpufreq_governor() was called within acpi_os_execute_deferred kernel thread context. To fix this panic issue, add pointer checking code in __cpufreq_governor() before pointer policy->governor is to be dereferenced. Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit (git 2.34.1) at 2025-10-02 03:12:43 +0000