summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-01-24Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs Pull btrfs fixes from Chris Mason: "We have a few fixes in my for-linus branch. Qu Wenruo's batch fix a regression between some our merge window pull and the inode_cache feature. The rest are smaller bugs" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: btrfs: Don't call btrfs_start_transaction() on frozen fs to avoid deadlock. btrfs: Fix the bug that fs_info->pending_changes is never cleared. btrfs: fix state->private cast on 32 bit machines Btrfs: fix race deleting block group from space_info->ro_bgs list Btrfs: fix incorrect freeing in scrub_stripe btrfs: sync ioctl, handle errors after transaction start
2015-01-24Merge tag 'platform-drivers-x86-v3.19-2' of ↵Linus Torvalds
git://git.infradead.org/users/dvhart/linux-platform-drivers-x86 Pull platform driver fix from Darren Hart: "Revert keyboard backlight sysfs support and documentation. The support for the dell-laptop keyboard backlight was flawed and the fix: https://lkml.org/lkml/2015/1/14/539 was more invasive that I felt comfortable sending at RC5. This series reverts the support for the dell-laptop keyboard backlight as well as the documentation for the newly created sysfs attributes. We'll get this implemented correctly for 3.20" * tag 'platform-drivers-x86-v3.19-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86: Revert "platform: x86: dell-laptop: Add support for keyboard backlight" Revert "Documentation: Add entry for dell-laptop sysfs interface"
2015-01-24Merge tag 'pci-v3.19-fixes-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI fixes from Bjorn Helgaas: "These are fixes for: - a resource management problem that causes a Radeon "Fatal error during GPU init" on machines where the BIOS programmed an invalid Root Port window. This was a regression in v3.16. - an Atheros AR93xx device that doesn't handle PCI bus resets correctly. This was a regression in v3.14. - an out-of-date email address" * tag 'pci-v3.19-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: MAINTAINERS: Update Richard Zhu's email address sparc/PCI: Clip bridge windows to fit in upstream windows powerpc/PCI: Clip bridge windows to fit in upstream windows parisc/PCI: Clip bridge windows to fit in upstream windows mn10300/PCI: Clip bridge windows to fit in upstream windows microblaze/PCI: Clip bridge windows to fit in upstream windows ia64/PCI: Clip bridge windows to fit in upstream windows frv/PCI: Clip bridge windows to fit in upstream windows alpha/PCI: Clip bridge windows to fit in upstream windows x86/PCI: Clip bridge windows to fit in upstream windows PCI: Add pci_claim_bridge_resource() to clip window if necessary PCI: Add pci_bus_clip_resource() to clip to fit upstream window PCI: Pass bridge device, not bus, when updating bridge windows PCI: Mark Atheros AR93xx to avoid bus reset PCI: Add flag for devices where we can't use bus reset
2015-01-24Merge tag 'devicetree-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux Pull devicetree bug fixes and documentation updates from Grant Likely: "A few bugfixes for the new DT overlay feature, documentation updates, spelling corrections, and changes to MAINTAINERS. Nothing earth shattering here" * tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux: of/unittest: Overlays with sub-devices tests of/platform: Handle of_populate drivers in notifier of/overlay: Do not generate duplicate nodes devicetree: document the "qemu" and "virtio" vendor prefixes devicetree: document ARM bindings for QEMU's Firmware Config interface Documentation: of: fix typo in graph bindings dma-mapping: fix debug print to display correct dma_pfn_offset of: replace Asahi Kasei Corp vendor prefix ARM: dt: GIC: Spelling s/specific/specifier/, s/flaggs/flags/ dt/bindings: arm-boards: Spelling s/pointong/pointing/ MAINTAINERS: Update DT website and git repository MAINTAINERS: drop DT regex matching on of_get_property and of_match_table
2015-01-23Merge tag 'imx-fixes-3.19-2' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes Merge "ARM: imx: fixes for 3.19, 2nd round" from Shawn Guo: The i.MX fixes for 3.19, 2nd round: - Correct pwm clock assignment in i.MX25 device tree to fix the broken pwm support on i.MX25 * tag 'imx-fixes-3.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: imx25: Fix PWM "per" clocks Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-23arm64: dts: add baud rate to Juno stdout-pathRobin Murphy
Without explicit command-line parameters, the Juno UART ends up running at 57600 baud in the kernel, which is at odds with the 115200 baud used by the rest of the firmware. Since commit 7914a7c5651a5161 now lets us fix this by specifying default options in stdout-path, do so. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-23PM / Domains: Remove pm_genpd_dev_need_restore() APIUlf Hansson
There are currently no users of this API, let's remove it. Additionally, if such feature would be needed future wise, a better option is likely use pm_runtime_set_active|suspended() in some form. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23PM / hibernate: Remove unused functionRickard Strandqvist
Remove the function get_safe_write_buffer() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23Merge tag 'mvebu-fixes-3.19-4' of git://git.infradead.org/linux-mvebu into fixesOlof Johansson
Merge "mvebu/fixes #3" from Andrew Lunn: mvebu fixes for 3.19. (Part 4) bus: mvebu-mbus: fix support of MBus window 13 * tag 'mvebu-fixes-3.19-4' of git://git.infradead.org/linux-mvebu: bus: mvebu-mbus: fix support of MBus window 13 ARM: mvebu: completely disable hardware I/O coherency Signed-off-by: Olof Johansson <olof@lixom.net>
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-24Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Paolo Bonzini: "Three small fixes. Two for x86 and one avoids that sparse bails out" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86: SYSENTER emulation is broken KVM: x86: Fix of previously incomplete fix for CVE-2014-8480 KVM: fix sparse warning in include/trace/events/kvm.h
2015-01-24Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-armLinus Torvalds
Pull ARM fixes from Russell King: "Another round of small ARM fixes. restore_user_regs early stack deallocation is buggy in the presence of FIQs which switch to SVC mode, and could lead to corrupted registers being returned to a user process given an inopportune FIQ event. Another bug was spotted in the ARM perf code where it could lose track of perf counter overflows, leading to incorrect perf results. Lastly, a bug in arm_add_memory() was spotted where the memory sizes aren't properly rounded. As most people pass properly rounded sizes, this hasn't been noticed" * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: ARM: 8292/1: mm: fix size rounding-down of arm_add_memory() function ARM: 8255/1: perf: Prevent wraparound during overflow ARM: 8266/1: Remove early stack deallocation from restore_user_regs
2015-01-24Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull two arm64 fixes from Will Deacon: "Arm64 fixes seem to come in pairs recently. We've got a fix for removing device-tree blobs when doing a make clean and another one addressing a missing include, which fixes build failures in -next for allmodconfig (spotted by Mark's buildbot). Summary from signed tag: - fix cleaning of .dtbs following directory restructuring - fix allmodconfig build breakage in -next due to missing include" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: dump: Fix implicit inclusion of definition for PCI_IOBASE arm64: Add dtb files to archclean rule
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-23PM / OPP: Assert RCU lock in exported functionsKrzysztof Kozlowski
Add lockdep asserts for holding the RCU lock when calling dev_pm_opp_get_freq() and dev_pm_opp_get_voltage() to aid in detecting RCU misuses. These are called often after dev_pm_opp_find_freq_ceil/exact() which already asserts for RCU lock. However one could make an error by releasing lock too early - just after dev_pm_opp_find_freq_ceil(). Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23PM / QoS: Use lockdep asserts to find missing hold of power.lockKrzysztof Kozlowski
Add lockdep asserts for holding the dev->power.lock to non-static functions which require this. They could be used outside of the file so asserts may help in detecting locking misuse. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23PM / OPP: Update kernel documentationNishanth Menon
kernel doc has gotten bit-rotted over time. Re-sync with Locking and Return information. document all functions properly and ensure that ./scripts/kernel-doc -v ./drivers/base/power/opp.c >/dev/null returns no errors Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23PM / OPP: Ensure consistent naming of static functionsNishanth Menon
All exported functions use dev_pm_* prefix and all static functions are now standardized with _ prefix. This is better than having to deal with multiple function naming styles within the same file. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-23PM / OPP: export dev_pm_opp_get_notifierNishanth Menon
Allows user drivers such as devfreq to be modules. Signed-off-by: Nishanth Menon <nm@ti.com> 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>