summaryrefslogtreecommitdiffstats
path: root/drivers/thermal
Commit message (Collapse)AuthorAgeFilesLines
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2015-01-274-9/+16
|\ | | | | | | | | | | | | | | | | | | Conflicts: arch/arm/boot/dts/imx6sx-sdb.dts net/sched/cls_bpf.c Two simple sets of overlapping changes. Signed-off-by: David S. Miller <davem@davemloft.net>
| * Merge branch 'thermal-soc' of ↵Linus Torvalds2015-01-154-9/+16
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux Pull thermal fixes from Zhang Rui: "Specifics: - bogus type qualifier fix in OF thermal code. - Minor fixes on imx and rcar thermal drivers. - Update TI SoC thermal maintainer entry. - Updated documentation of OF cpufreq cooling register" * 'thermal-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: thermal: rcar: Spelling/grammar: s/drier use .../driver uses ...s/ thermal: rcar: change type of ctemp in rcar_thermal_update_temp() thermal: rcar: fix ENR register value Documentation: thermal: document of_cpufreq_cooling_register() Thermal: imx: add clk disable/enable for suspend/resume MAINTAINERS: update ti-soc-thermal status MAINTAINERS: Add linux-omap to list of reviewers for TI Thermal thermal: of: Remove bogus type qualifier for of_thermal_get_trip_points()
| | * thermal: rcar: Spelling/grammar: s/drier use .../driver uses ...s/Geert Uytterhoeven2015-01-121-1/+1
| | | | | | | | | | | | | | | Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * thermal: rcar: change type of ctemp in rcar_thermal_update_temp()Yoshihiro Shimoda2015-01-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the ctemp is used for rcar_thermal_write() in rcar_thermal_update_temp(), the type of 'ctemp' should be "u32" instead of "int". This patch also changes type of the helper variables 'old' and 'new'. Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * thermal: rcar: fix ENR register valueYoshihiro Shimoda2015-01-071-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On R-Mobile APE6, since it has 3 thermal zones, ENR register has enable bits in bit 19-16, bit 11-8 and bit 3-0. However, on R-Car gen2, since it has 1 thermal zone, ENR register has enable bits in bit 3-0. (In other words, the write value should always be 0 for bit 31-4 of ENR register.) So, this patch fixes the ENR register value using I/O resource sets. Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * Thermal: imx: add clk disable/enable for suspend/resumeAnson Huang2015-01-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Thermal sensor's clk is from pll3_usb_otg, per hardware design requirement, need to make sure pll3_usb_otg is disabled before STOP mode is entered, otherwise, all PFDs under it may enter incorrect state, this patch disables pll3_usb_otg before suspend and enables it after resume. Signed-off-by: Anson Huang <b20788@freescale.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * thermal: of: Remove bogus type qualifier for of_thermal_get_trip_points()Geert Uytterhoeven2015-01-052-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With gcc 4.1.2, 4.2, and 4.2.4 (4.4 and later are OK): drivers/thermal/thermal_core.h:110: warning: type qualifiers ignored on function return type Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: ce8be7785922de0e ("thermal: of: Extend of-thermal to export table of trip points") Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
* | | netlink: make nlmsg_end() and genlmsg_end() voidJohannes Berg2015-01-181-5/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Contrary to common expectations for an "int" return, these functions return only a positive value -- if used correctly they cannot even return 0 because the message header will necessarily be in the skb. This makes the very common pattern of if (genlmsg_end(...) < 0) { ... } be a whole bunch of dead code. Many places also simply do return nlmsg_end(...); and the caller is expected to deal with it. This also commonly (at least for me) causes errors, because it is very common to write if (my_function(...)) /* error condition */ and if my_function() does "return nlmsg_end()" this is of course wrong. Additionally, there's not a single place in the kernel that actually needs the message length returned, and if anyone needs it later then it'll be very easy to just use skb->len there. Remove this, and make the functions void. This removes a bunch of dead code as described above. The patch adds lines because I did - return nlmsg_end(...); + nlmsg_end(...); + return 0; I could have preserved all the function's return values by returning skb->len, but instead I've audited all the places calling the affected functions and found that none cared. A few places actually compared the return value with <= 0 in dump functionality, but that could just be changed to < 0 with no change in behaviour, so I opted for the more efficient version. One instance of the error I've made numerous times now is also present in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't check for <0 or <=0 and thus broke out of the loop every single time. I've preserved this since it will (I think) have caused the messages to userspace to be formatted differently with just a single message for every SKB returned to userspace. It's possible that this isn't needed for the tools that actually use this, but I don't even know what they are so couldn't test that changing this behaviour would be acceptable. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | int340x_thermal/processor_thermal_device: return failure whenZhang Rui2015-01-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | there is no ACPI device object processor_thermal_device driver needs ACPI support to work. Thus, the driver probing should fail when there is no ACPI device object asscociated. This fixes a NULL pointer dereference when the driver is loaded with INT340X feature disabled in BIOS. Reported-by: Chen Yu <yu.c.chen@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com>
* | ACPI/int340x_thermal: enumerate INT340X devices even if they're not in _ART/_TRTZhang Rui2015-01-061-12/+4
|/ | | | | | | | | | For some INT340X thermal devices, even if they are not referred in _TRT/_ART table, they still can be used by userspace for thermal control. Thus change the code to enumerated all the INT340X devices, no matter if they're referred in _TRT/_ART or not. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
*-. Merge branches 'thermal-core', 'thermal-soc' and 'thermal-int340x' of .git ↵Zhang Rui2014-12-2416-271/+491
|\ \ | | | | | | | | | into next
| | * Thermal/int340x/int3403: Free acpi notification handlerSrinivas Pandruvada2014-12-241-0/+2
| | | | | | | | | | | | | | | | | | | | | Remove acpi notification handler when zone is removed. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * Thermal/int340x/processor_thermal: Fix memory leakSrinivas Pandruvada2014-12-241-9/+20
| | | | | | | | | | | | | | | | | | | | | Address memory leak for buffer allocated with ACPI_ALLOCATE_BUFFER. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * Thermal/int340x/int3403: Fix memory leakSrinivas Pandruvada2014-12-241-0/+2
| | | | | | | | | | | | | | | | | | | | | Address memory leak for buffer allocated with ACPI_ALLOCATE_BUFFER. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * thermal: int340x: Introduce processor reporting deviceSrinivas Pandruvada2014-12-242-0/+299
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Int340x thermal provides a processor thermal device, which is used to control processor thermal states. These devices are either reported as a PCI device or an ACPI device. This device provides power limits, control states and optional temperature. This change implements minimal requirements to expose processor power limits which can be used during thermal power limiting. Power limits are exposed via an attribute group called "power_limits" under the device. The exported attributes are: power_limit_0_max_uw power_limit_1_max_uw power_limit_0_min_uw power_limit_1_min_uw power_limit_0_tmin_us power_limit_1_tmin_us power_limit_0_tmax_us power_limit_1_tmax_us power_limit_0_step_uw power_limit_1_step_uw Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * thermal: int340x_thermal: drop owner assignment from platform_driversWolfram Sang2014-12-222-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * Thermal/int340x: Handle properly the case when _trt or _art acpi entry is ↵Ilkka Koskinen2014-12-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | missing If either of the entries was missing, the driver tried to free memory using uninitialized pointer. In addition, it was dereferencing null pointer. Signed-off-by: Ilkka Koskinen <ilkka.koskinen@linux.intel.com> Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| * | thermal: drop owner assignment from platform_driversWolfram Sang2014-12-221-1/+0
| | | | | | | | | | | | | | | | | | | | | 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>
| * | Merge branch 'fixes' of ↵Zhang Rui2014-12-218-264/+172
| |\ \ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal into thermal-soc
| | * | thermal: cpu_cooling: small memory leak on errorDan Carpenter2014-12-171-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a left over return here so the error handling isn't run. It leads to a small memory leak and a static checker warning. drivers/thermal/cpu_cooling.c:351 __cpufreq_cooling_register() info: ignoring unreachable code. Fixes: f6859014c7e7 ("thermal: cpu_cooling: Store frequencies in descending order") Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: ti-soc-thermal: Do not print error message in the EPROBE_DEFER caseEduardo Valentin2014-12-121-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Avoid printing the error message in the EPROBE_DEFER case where registering cpu cooling at ti-soc-thermal thermal driver. Cc: Zhang Rui <rui.zhang@intel.com> Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: db8500: Do not print error message in the EPROBE_DEFER caseEduardo Valentin2014-12-121-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Avoid printing the error message in the EPROBE_DEFER case where registering cpu cooling at db8500 thermal driver. Cc: Zhang Rui <rui.zhang@intel.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: devicetree@vger.kernel.org Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: imx: Do not print error message in the EPROBE_DEFER caseFabio Estevam2014-12-121-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During imx_thermal probe we have the following log: [ 1.514819] imx_thermal 2000000.aips-bus:tempmon: failed to register cpufreq cooling device: -517 [ 1.515064] platform 2000000.aips-bus:tempmon: Driver imx_thermal requests probe deferral Avoid printing the error message in the EPROBE_DEFER case. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | drivers: thermal: Remove ARCH_HAS_BANDGAP dependency for samsungAbhilash Kesavan2014-12-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As samsung thermal support is enabled only for ARCH_EXYNOS, there is no need to select ARCH_HAS_BANDGAP from the arch-specific code. Removing this dependency will also allow the driver to be enabled on 64-bit SoCs. Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: Lukasz Majewski <l.majewski@samsung.com> Acked-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal:core:fix: Check return code of the ->get_max_state() callbackLukasz Majewski2014-12-081-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The return code from ->get_max_state() callback was not checked during binding cooling device to thermal zone device. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: update copyright tagsViresh Kumar2014-12-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding my copyright information for two purposes: - To get cc'd for future patches to review (Only if people read this header while sending mail) - Have done enough changes to earn a place here? Cc: Amit Daniel Kachhap <amit.daniel@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: Use cpufreq_dev->freq_table for finding level/freqViresh Kumar2014-12-081-89/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | get_property() was an over complicated beast with BUGs. It used to believe that cpufreq table is present in ascending or descending order, which might not always be true. Previous patch has created another freq table in descending order for us and we better use it now. With that get_property() simply goes away and another helper get_level() comes in. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: Store frequencies in descending orderViresh Kumar2014-12-081-1/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CPUFreq framework *doesn't* guarantee that frequencies present in cpufreq table will be in ascending or descending order. But cpu_cooling somehow assumes that. Probably because most of current users are creating this list from DT, which is done with the help of OPP layer. And OPP layer creates the list in ascending order of frequencies. But cpu_cooling can be used for other platforms too, which don't have frequencies arranged in any order. This patch tries to fix this issue by creating another list of valid frequencies in descending order. Care is also taken to throw warnings for duplicate entries. Later patches would use it to simplify code. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: Pass 'cpufreq_dev' to get_property()Viresh Kumar2014-12-081-23/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already know the value of 'cpufreq_dev->max_level' and so there is no need calculating that once again. For this, we need to send 'cpufreq_dev' to get_property(). Make all necessary changes for this change. Because cpufreq_cooling_get_level() doesn't have access to 'cpufreq_dev', it is updated to iterate over the list of cpufreq_cooling_devices to get cooling device for the cpu number passed to it. This also makes it robust to return levels only for the CPU registered via a cooling device. We don't have to support anything that isn't registered yet. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: use cpufreq_dev_list instead of cpufreq_dev_countViresh Kumar2014-12-081-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As we already have a list of cpufreq_cooling_devices now, lets use it instead of a local counter. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: get_property() doesn't need to support GET_MAXL anymoreViresh Kumar2014-12-081-11/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't use get_property() to find max levels anymore as it is done at boot now. So, don't support GET_MAXL in get_property(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: find max level during device registrationViresh Kumar2014-12-081-13/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CPU frequency tables don't update after the driver is registered and so we don't need to iterate over them to find total number of states every time cpufreq_get_max_state() is called. Do it once at boot time. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: remove unnecessary wrapper get_cpu_frequency()Viresh Kumar2014-12-081-31/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | get_cpu_frequency() isn't doing much by itself, just calling get_property(). And so this wrapper isn't required at all. Get rid of it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: Merge cpufreq_apply_cooling() into cpufreq_set_cur_state()Viresh Kumar2014-12-081-36/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cpufreq_apply_cooling() has a single caller, cpufreq_set_cur_state() and cpufreq_set_cur_state() is an unnecessary wrapper over cpufreq_apply_cooling(). Get rid of it by merging both routines. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: initialize 'cpufreq_val' on registrationViresh Kumar2014-12-081-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no point checking for validity of 'cpufreq_val' from cpufreq_thermal_notifier() every time the routine is called. Its guaranteed to be 0 on the first call but will be valid otherwise. Lets update it once while the device registers. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: do error handling at the bottom in ↵Viresh Kumar2014-12-081-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | __cpufreq_cooling_register() This makes life easy and bug free. And is scalable for future resource allocations. Acked-by: Javi Merino <javi.merino@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: Don't check is_cpufreq_valid()Viresh Kumar2014-12-081-19/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because get_cpu_frequency() has returned a valid frequency, it means that the cpufreq policy is surely valid and so no point checking that again with is_cpufreq_valid(). Get rid of the routine as well as there are no more users. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: don't iterate over all allowed_cpus to update cpufreq ↵Viresh Kumar2014-12-081-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | policy All CPUs present in 'allowed_cpus' share the same 'struct cpufreq_policy' structure and so calling cpufreq_update_policy() for each of them doesn't make sense. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: Don't match min/max frequencies for all CPUs on ↵Viresh Kumar2014-12-081-17/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cooling register In __cpufreq_cooling_register() we try to match min/max frequencies for all CPUs passed in 'clip_cpus' mask. This mask is the cpumask of cpus where the frequency constraints will be applied. Same frequency constraint can be applied only to the CPUs belonging to the same cluster (i.e. CPUs sharing clock line). For all such CPUs we have a single 'struct cpufreq_policy' structure managing them and so getting policies for all CPUs wouldn't make any sense as they will all return the same pointer. So, remove this useless check of checking min/max for all CPUs. Also update doc comment to make this more obvious that clip_cpus should be same as policy->related_cpus. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: propagate error returned by idr_alloc()Viresh Kumar2014-12-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We aren't supposed to return our own error type here. Return what we got. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: no need to initialze 'ret'Viresh Kumar2014-12-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ret is initialized before it is used, so no need to set it to 0 in its declaration. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: no need to set cpufreq_dev to NULLViresh Kumar2014-12-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It will be overwritten soon with return value of kzalloc(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: no need to set cpufreq_state to zeroViresh Kumar2014-12-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Its already zero, we allocated cpufreq_dev with kzalloc. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: Pass variable instead of its type to sizeof()Viresh Kumar2014-12-081-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Just following coding guidelines here. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: Add comment to clarify relation between cooling state ↵Viresh Kumar2014-12-081-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and frequency This wasn't explained well anywhere and should be clearly specified. Lets add a top level comment for this. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: fix doc comment over struct cpufreq_cooling_deviceViresh Kumar2014-12-081-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cooling_cpufreq_lock isn't used to protect this structure and so the comment over it is outdated. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: cpu_cooling: random comment fixupsViresh Kumar2014-12-081-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | s/give/given Acked-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: exynos: pass cpu_present_mask to cpufreq_cooling_register()Viresh Kumar2014-12-081-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cpufreq_cooling_register() expects mask of all the CPUs where frequency constraint is applicable. This platform has more than one CPU to which these constraints will apply and so passing mask of only CPU0 wouldn't be sufficient. Also, this platform has a single cluster of CPUs and the constraint applies to all CPUs. If CPU0 is hoplugged out then we may face strange BUGs as cpu_cooling framework isn't aware of any siblings sharing clock line. Fix it by passing cpu_present_mask to cpufreq_cooling_register(). Cc: Chanwoo Choi <cw00.choi@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Amit Daniel Kachhap <amit.daniel@samsung.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: imx: pass cpu_present_mask to cpufreq_cooling_register()Viresh Kumar2014-12-081-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cpufreq_cooling_register() expects mask of all the CPUs where frequency constraint is applicable. This platform has more than one CPU to which these constraints will apply and so passing mask of only CPU0 wouldn't be sufficient. Also, this platform has a single cluster of CPUs and the constraint applies to all CPUs. If CPU0 is hoplugged out then we may face strange BUGs as cpu_cooling framework isn't aware of any siblings sharing clock line. Fix it by passing cpu_present_mask to cpufreq_cooling_register(). Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * | thermal: db8500: pass cpu_present_mask to cpufreq_cooling_register()Viresh Kumar2014-12-081-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cpufreq_cooling_register() expects mask of all the CPUs where frequency constraint is applicable. This platform has more than one CPU to which these constraints will apply and so passing mask of only CPU0 wouldn't be sufficient. Also, this platform has a single cluster of CPUs and the constraint applies to all CPUs. If CPU0 is hoplugged out then we may face strange BUGs as cpu_cooling framework isn't aware of any siblings sharing clock line. Fix it by passing cpu_present_mask to cpufreq_cooling_register(). Cc: Hongbo Zhang <hongbo.zhang@linaro.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
OpenPOWER on IntegriCloud