summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'next' of ↵Linus Torvalds2014-10-2431-422/+2222
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux Pull thermal management updates from Zhang Rui: "Sorry that I missed the merge window as there is a bug found in the last minute, and I have to fix it and wait for the code to be tested in linux-next tree for a few days. Now the buggy patch has been dropped entirely from my next branch. Thus I hope those changes can still be merged in 3.18-rc2 as most of them are platform thermal driver changes. Specifics: - introduce ACPI INT340X thermal drivers. Newer laptops and tablets may have thermal sensors and other devices with thermal control capabilities that are exposed for the OS to use via the ACPI INT340x device objects. Several drivers are introduced to expose the temperature information and cooling ability from these objects to user-space via the normal thermal framework. From: Lu Aaron, Lan Tianyu, Jacob Pan and Zhang Rui. - introduce a new thermal governor, which just uses a hysteresis to switch abruptly on/off a cooling device. This governor can be used to control certain fan devices that can not be throttled but just switched on or off. From: Peter Feuerer. - introduce support for some new thermal interrupt functions on i.MX6SX, in IMX thermal driver. From: Anson, Huang. - introduce tracing support on thermal framework. From: Punit Agrawal. - small fixes in OF thermal and thermal step_wise governor" * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (25 commits) Thermal: int340x thermal: select ACPI fan driver Thermal: int3400_thermal: use acpi_thermal_rel parsing APIs Thermal: int340x_thermal: expose acpi thermal relationship tables Thermal: introduce int3403 thermal driver Thermal: introduce INT3402 thermal driver Thermal: move the KELVIN_TO_MILLICELSIUS macro to thermal.h ACPI / Fan: support INT3404 thermal device ACPI / Fan: add ACPI 4.0 style fan support ACPI / fan: convert to platform driver ACPI / fan: use acpi_device_xxx_power instead of acpi_bus equivelant ACPI / fan: remove no need check for device pointer ACPI / fan: remove unused macro Thermal: int3400 thermal: register to thermal framework Thermal: int3400 thermal: add capability to detect supporting UUIDs Thermal: introduce int3400 thermal driver ACPI: add ACPI_TYPE_LOCAL_REFERENCE support to acpi_extract_package() ACPI: make acpi_create_platform_device() an external API thermal: step_wise: fix: Prevent from binary overflow when trend is dropping ACPI: introduce ACPI int340x thermal scan handler thermal: Added Bang-bang thermal governor ...
| * Merge branch 'int340x-thermal' of .git into nextZhang Rui2014-10-1722-408/+1867
| |\
| | * Thermal: int340x thermal: select ACPI fan driverZhang Rui2014-10-172-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | we share the same driver for both ACPI predefined Fan device and INT3404 Fan device, thus we should select the ACPI Fan driver when int340x thermal drivers are enabeld. Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * Thermal: int3400_thermal: use acpi_thermal_rel parsing APIsJacob Pan2014-10-111-159/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI _TRT and _ART parsing code has been moved to acpi_thermal_rel such that it can be used by other devices in the future. Use the parsing APIs in acpi_thermal_rel.c instead. Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * Thermal: int340x_thermal: expose acpi thermal relationship tablesJacob Pan2014-10-114-0/+490
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI 4.0 introduced two thermal relationship tables via _ART (active cooling) and _TRT (passive cooling) objects. These tables contain many to many relationships among thermal sensors and cooling devices. This patch parses _ART and _TRT and makes the result available to the userspace via an misc device interface. At the same time, kernel drivers can also request parsing results from internal kernel APIs. The results include source and target devices, influence, and sampling rate in case of _TRT. For _ART, the result shows source device, target device, and weight percentage. Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * Thermal: introduce int3403 thermal driverLan Tianyu2014-10-115-312/+478
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI INT3403 device object can be used to retrieve temperature date from temperature sensors present in the system, and to expose device' performance control. The previous INT3403 thermal driver supports temperature reporting only, thus remove it and introduce this new & enhanced one. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * Thermal: introduce INT3402 thermal driverAaron Lu2014-10-103-0/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI INT3402 device object could report temperature for the memory module. To expose such information to user space, a thermal zone device is registered for it so that the thermal sysfs interface can expose such information for userspace to use. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * Thermal: move the KELVIN_TO_MILLICELSIUS macro to thermal.hAaron Lu2014-10-102-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | This macro can be used by other component so move it to a common header, but in a slightly different way: define two macros, one macro with an offset and the other doesn't. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * ACPI / Fan: support INT3404 thermal deviceAaron Lu2014-10-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | INT3404 ACPI object follows the ACPI 5.0 fan object definition as described in section 11.3 of the ACPI 5.0 Specification. Thus we can reuse the ACPI fan driver for INT3404 ACPI object. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * ACPI / Fan: add ACPI 4.0 style fan supportAaron Lu2014-10-101-27/+241
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for ACPI 4.0 style fan, lacking part is: no support for 'Low Speed Notification Support', 'Fine Grain Control' is not used yet. It's not clear what to do on suspend/resume callback for 4.0 style ACPI fan, so it does nothing for now. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * ACPI / fan: convert to platform driverAaron Lu2014-10-101-34/+28
| | | | | | | | | | | | | | | | | | | | | | | | Convert ACPI fan driver to a platform driver for the purpose of phasing out ACPI bus. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * ACPI / fan: use acpi_device_xxx_power instead of acpi_bus equivelantAaron Lu2014-10-104-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we have the acpi_device pointer, there is no need to pass the device's handle to the acpi_bus_xxx_power functions to get/set/update the device's power state, instead, use the acpi_device_xxx_power functions directly. To make this happen for fan module, export acpi_device_update_power. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * ACPI / fan: remove no need check for device pointerAaron Lu2014-10-101-17/+1
| | | | | | | | | | | | | | | | | | | | | | | | The device pointer will not be NULL in the PM callback and ACPI driver's add/remove callback, so checking NULL for them isn't necessary. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * ACPI / fan: remove unused macroAaron Lu2014-10-101-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | The _COMPONENT, ACPI_MODULE_NAME(name) and ACPI_FAN_FILE_STATE are not used anywhere so remove them. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * Thermal: int3400 thermal: register to thermal frameworkZhang Rui2014-10-102-0/+104
| | | | | | | | | | | | Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * Thermal: int3400 thermal: add capability to detect supporting UUIDsZhang Rui2014-10-101-0/+69
| | | | | | | | | | | | Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * Thermal: introduce int3400 thermal driverZhang Rui2014-10-105-2/+249
| | | | | | | | | | | | | | | | | | | | | Introduce int3400 thermal driver. And make INT3400 driver enumerate the other int340x thermal components shown in _ART/_TRT. Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * ACPI: add ACPI_TYPE_LOCAL_REFERENCE support to acpi_extract_package()Zhang Rui2014-10-101-1/+27
| | | | | | | | | | | | | | | | | | | | | Add ACPI_TYPE_LOCAL_REFERENCE support to acpi_extract_package(), so that we can use this helper for more cases like _ART/_TRT. Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * ACPI: make acpi_create_platform_device() an external APIZhang Rui2014-10-103-7/+2
| | | | | | | | | | | | Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| | * ACPI: introduce ACPI int340x thermal scan handlerZhang Rui2014-09-115-0/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Newer laptops and tablets that use ACPI may have thermal sensors and other devices with thermal control capabilities outside the core CPU/SOC, for thermal safety reasons. They are exposed for the OS to use via 1) INT3400 ACPI device object as the master. 2) INT3401 ~ INT340B ACPI device objects as the slaves. This patch introduces a scan handler to enumerate the INT3400 ACPI device object to platform bus, and prevent its slaves from being enumerated before the controller driver being probed. Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| * | Merge branch 'thermal-core-fix' of .git into nextZhang Rui2014-10-111-1/+1
| |\ \
| | * | thermal: step_wise: fix: Prevent from binary overflow when trend is droppingLukasz Majewski2014-10-091-1/+1
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that some boards can have instance->lower greater than 0 and when thermal trend is dropping it results with next_target equal to -1. Since the next_target is defined as unsigned long it is interpreted as 0xFFFFFFFF and larger than instance->upper. As a result the next_target is set to instance->upper which ramps up to maximal cooling device target when the temperature is steadily decreasing. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| * | Merge branches 'eduardo-soc' and 'bang-bang-governor' of .git into nextZhang Rui2014-09-185-0/+155
| |\ \
| | * | thermal: Added Bang-bang thermal governorPeter Feuerer2014-08-275-0/+155
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bang-bang thermal governor uses a hysteresis to switch abruptly on or off a cooling device. It is intended to control fans, which can not be throttled but just switched on or off. Bang-bang cannot be set as default governor as it is intended for special devices only. For those special devices the driver needs to explicitely request it. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Andreas Mohr <andi@lisas.de> Cc: Borislav Petkov <bp@suse.de> Cc: Javi Merino <javi.merino@arm.com> Cc: linux-pm@vger.kernel.org Signed-off-by: Peter Feuerer <peter@piie.net> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
| * | Merge branch 'next' of ↵Zhang Rui2014-08-277-15/+200
| |\ \ | | |/ | |/| | | | git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal into eduardo-soc
| | * Thermal: imx: add i.mx6sx thermal supportAnson Huang2014-08-092-14/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i.MX6SX has some new features of thermal interrupt function, there are LOW, HIGH and PANIC irq for thermal sensor, so add platform data to separate different thermal version; The reset value of LOW ALARM is 0 which means the highest temp, so the LOW ALARM will be triggered once irq is enabled, so we need to correct it before enabling thermal irq; Enable PANIC ALARM as critical trip point, it will trigger system reset via SRC module once PANIC IRQ is triggered, it is pure hardware function, so use it instead of software reset by cooling device. Signed-off-by: Anson Huang <b20788@freescale.com> Tested-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * thermal: add support to disable thermal zone from DTSLaxman Dewangan2014-07-291-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support to check status of the thermal zone before registering the zone. This will help on disabling some non-existing thermal zone from the top level DTS file out of common dtsi thermalzone file. For example, we have 3 platforms almost same but thermal zones on this platform are little bit different. Platform 1 and 2 have three thermal zones and platform 3 has two thermal zones. To avoid duplication of the thermal zones entries on each DTS file of platforms,we created one common dtsi file for thermal zone and included this dtsi file from these 3 platform's top level dts file. On common thermal zone com dtsi file, all thermal zone are enabled and need to disable one of thermal zone on platform 3 dts file. For this, we just added entry status = "disabled" for that thermal zone on platform 3 dts file and along with this change to make it work. This way, we reuse the common file and control the enable/disable of the thermal zone from top level dts file. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * thermal: trace: Trace when temperature is above a trip pointPunit Agrawal2014-07-294-1/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a new event to trace when the temperature is above a trip point. Use the trace-point when handling non-critical and critical trip pionts. Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * thermal: trace: Trace when a cooling device's state is updatedPunit Agrawal2014-07-292-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce and use an event to trace when a cooling device's state is updated. This is useful to follow the effect of governor decisions on cooling devices. Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
| | * thermal: trace: Trace temperature changesPunit Agrawal2014-07-292-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a new event to trace the temperature of a thermal zone. Using this event trace the temperature changes of the thermal zone every-time it is updated. Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
* | | Merge tag 'remove-weak-declarations' of ↵Linus Torvalds2014-10-238-28/+21
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull weak function declaration removal from Bjorn Helgaas: "The "weak" attribute is commonly used for the default version of a function, where an architecture can override it by providing a strong version. Some header file declarations included the "weak" attribute. That's error-prone because it causes every implementation to be weak, with no strong version at all, and the linker chooses one based on link order. What we want is the "weak" attribute only on the *definition* of the default implementation. These changes remove "weak" from the declarations, leaving it on the default definitions" * tag 'remove-weak-declarations' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: uprobes: Remove "weak" from function declarations memory-hotplug: Remove "weak" from memory_block_size_bytes() declaration kgdb: Remove "weak" from kgdb_arch_pc() declaration ARC: kgdb: generic kgdb_arch_pc() suffices vmcore: Remove "weak" from function declarations clocksource: Remove "weak" from clocksource_default_clock() declaration x86, intel-mid: Remove "weak" from function declarations audit: Remove "weak" from audit_classify_compat_syscall() declaration
| * | | uprobes: Remove "weak" from function declarationsBjorn Helgaas2014-10-221-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the following interfaces: set_swbp() set_orig_insn() is_swbp_insn() is_trap_insn() uprobe_get_swbp_addr() arch_uprobe_ignore() arch_uprobe_copy_ixol() kernel/events/uprobes.c provides default definitions explicitly marked "weak". Some architectures provide their own definitions intended to override the defaults, but the "weak" attribute on the declarations applied to the arch definitions as well, so the linker chose one based on link order (see 10629d711ed7 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node decl")). Remove the "weak" attribute from the declarations so we always prefer a non-weak definition over the weak one, independent of link order. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> CC: Victor Kamensky <victor.kamensky@linaro.org> CC: Oleg Nesterov <oleg@redhat.com> CC: David A. Long <dave.long@linaro.org> CC: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
| * | | memory-hotplug: Remove "weak" from memory_block_size_bytes() declarationBjorn Helgaas2014-10-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drivers/base/memory.c provides a default memory_block_size_bytes() definition explicitly marked "weak". Several architectures provide their own definitions intended to override the default, but the "weak" attribute on the declaration applied to the arch definitions as well, so the linker chose one based on link order (see 10629d711ed7 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node decl")). Remove the "weak" attribute from the declaration so we always prefer a non-weak definition over the weak one, independent of link order. Fixes: 41f107266b19 ("drivers: base: Add prototype declaration to the header file") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Andrew Morton <akpm@linux-foundation.org> CC: Rashika Kheria <rashika.kheria@gmail.com> CC: Nathan Fontenot <nfont@austin.ibm.com> CC: Anton Blanchard <anton@au1.ibm.com> CC: Heiko Carstens <heiko.carstens@de.ibm.com> CC: Yinghai Lu <yinghai@kernel.org>
| * | | kgdb: Remove "weak" from kgdb_arch_pc() declarationBjorn Helgaas2014-10-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | kernel/debug/debug_core.c provides a default kgdb_arch_pc() definition explicitly marked "weak". Several architectures provide their own definitions intended to override the default, but the "weak" attribute on the declaration applied to the arch definitions as well, so the linker chose one based on link order (see 10629d711ed7 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node decl")). Remove the "weak" attribute from the declaration so we always prefer a non-weak definition over the weak one, independent of link order. Fixes: 688b744d8bc8 ("kgdb: fix signedness mixmatches, add statics, add declaration to header") Tested-by: Vineet Gupta <vgupta@synopsys.com> # for ARC build Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Harvey Harrison <harvey.harrison@gmail.com>
| * | | ARC: kgdb: generic kgdb_arch_pc() sufficesVineet Gupta2014-10-221-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The ARC version of kgdb_arch_pc() is identical to the generic version in kernel/debug/debug_core.c. Drop the ARC version so we use the generic one. Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | | vmcore: Remove "weak" from function declarationsBjorn Helgaas2014-10-221-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the following functions: elfcorehdr_alloc() elfcorehdr_free() elfcorehdr_read() elfcorehdr_read_notes() remap_oldmem_pfn_range() fs/proc/vmcore.c provides default definitions explicitly marked "weak". arch/s390 provides its own definitions intended to override the default ones, but the "weak" attribute on the declarations applied to the s390 definitions as well, so the linker chose one based on link order (see 10629d711ed7 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node decl")). Remove the "weak" attribute from the declarations so we always prefer a non-weak definition over the weak one, independent of link order. Fixes: be8a8d069e50 ("vmcore: introduce ELF header in new memory feature") Fixes: 9cb218131de1 ("vmcore: introduce remap_oldmem_pfn_range()") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Vivek Goyal <vgoyal@redhat.com> CC: Michael Holzheu <holzheu@linux.vnet.ibm.com>
| * | | clocksource: Remove "weak" from clocksource_default_clock() declarationBjorn Helgaas2014-10-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | kernel/time/jiffies.c provides a default clocksource_default_clock() definition explicitly marked "weak". arch/s390 provides its own definition intended to override the default, but the "weak" attribute on the declaration applied to the s390 definition as well, so the linker chose one based on link order (see 10629d711ed7 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node decl")). Remove the "weak" attribute from the clocksource_default_clock() declaration so we always prefer a non-weak definition over the weak one, independent of link order. Fixes: f1b82746c1e9 ("clocksource: Cleanup clocksource selection") Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: John Stultz <john.stultz@linaro.org> Acked-by: Ingo Molnar <mingo@kernel.org> CC: Daniel Lezcano <daniel.lezcano@linaro.org> CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
| * | | x86, intel-mid: Remove "weak" from function declarationsBjorn Helgaas2014-10-221-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the following interfaces: get_penwell_ops() get_cloverview_ops() get_tangier_ops() there is only one implementation, so they do not need to be marked "weak". Remove the "weak" attribute from their declarations. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Ingo Molnar <mingo@kernel.org> CC: David Cohen <david.a.cohen@linux.intel.com> CC: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> CC: x86@kernel.org
| * | | audit: Remove "weak" from audit_classify_compat_syscall() declarationBjorn Helgaas2014-10-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's only one audit_classify_compat_syscall() definition, so it doesn't need to be weak. Remove the "weak" attribute from the audit_classify_compat_syscall() declaration. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Richard Guy Briggs <rgb@redhat.com> CC: AKASHI Takahiro <takahiro.akashi@linaro.org>
* | | | Merge branch 'x86-efi-for-linus' of ↵Linus Torvalds2014-10-2320-123/+528
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 EFI updates from Peter Anvin: "This patchset falls under the "maintainers that grovel" clause in the v3.18-rc1 announcement. We had intended to push it late in the merge window since we got it into the -tip tree relatively late. Many of these are relatively simple things, but there are a couple of key bits, especially Ard's and Matt's patches" * 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (24 commits) rtc: Disable EFI rtc for x86 efi: rtc-efi: Export platform:rtc-efi as module alias efi: Delete the in_nmi() conditional runtime locking efi: Provide a non-blocking SetVariable() operation x86/efi: Adding efi_printks on memory allocationa and pci.reads x86/efi: Mark initialization code as such x86/efi: Update comment regarding required phys mapped EFI services x86/efi: Unexport add_efi_memmap variable x86/efi: Remove unused efi_call* macros efi: Resolve some shadow warnings arm64: efi: Format EFI memory type & attrs with efi_md_typeattr_format() ia64: efi: Format EFI memory type & attrs with efi_md_typeattr_format() x86: efi: Format EFI memory type & attrs with efi_md_typeattr_format() efi: Introduce efi_md_typeattr_format() efi: Add macro for EFI_MEMORY_UCE memory attribute x86/efi: Clear EFI_RUNTIME_SERVICES if failing to enter virtual mode arm64/efi: Do not enter virtual mode if booting with efi=noruntime or noefi arm64/efi: uefi_init error handling fix efi: Add kernel param efi=noruntime lib: Add a generic cmdline parse function parse_option_str ...
| * \ \ \ Merge branch 'next' into efi-next-mergeMatt Fleming2014-10-0320-123/+528
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: arch/x86/boot/compressed/eboot.c
| | * | | | rtc: Disable EFI rtc for x86Matt Fleming2014-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit da167ad7638759 ("rtc: ia64: allow other architectures to use EFI RTC") inadvertently introduced a regression for x86 because we've been careful not to enable the EFI rtc driver due to the generally buggy implementations of the time-related EFI runtime services. In fact, since the above commit was merged we've seen reports of crashes on 32-bit tablets, https://bugzilla.kernel.org/show_bug.cgi?id=84241#c21 Disable it explicitly for x86 so that we don't give users false hope that this driver will work - it won't, and your machine is likely to crash. Acked-by: Mark Salter <msalter@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: <stable@vger.kernel.org> # v3.17 Signed-off-by: Matt Fleming <matt.fleming@intel.com>
| | * | | | efi: rtc-efi: Export platform:rtc-efi as module aliasArd Biesheuvel2014-10-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the rtc-efi driver is built as a module, we already register the EFI rtc as a platform device if UEFI Runtime Services are enabled. To wire it up to udev, and let the module be loaded automatically, we need to export the 'platform:rtc-efi' alias from the module. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Mark Salter <msalter@redhat.com> Cc: Dave Young <dyoung@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
| | * | | | efi: Delete the in_nmi() conditional runtime lockingMatt Fleming2014-10-032-15/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 5dc3826d9f08 ("efi: Implement mandatory locking for UEFI Runtime Services") implemented some conditional locking when accessing variable runtime services that Ingo described as "pretty disgusting". The intention with the !efi_in_nmi() checks was to avoid live-locks when trying to write pstore crash data into an EFI variable. Such lockless accesses are allowed according to the UEFI specification when we're in a "non-recoverable" state, but whether or not things are implemented correctly in actual firmware implementations remains an unanswered question, and so it would seem sensible to avoid doing any kind of unsynchronized variable accesses. Furthermore, the efi_in_nmi() tests are inadequate because they don't account for the case where we call EFI variable services from panic or oops callbacks and aren't executing in NMI context. In other words, live-locking is still possible. Let's just remove the conditional locking altogether. Now we've got the ->set_variable_nonblocking() EFI variable operation we can abort if the runtime lock is already held. Aborting is by far the safest option. Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
| | * | | | efi: Provide a non-blocking SetVariable() operationMatt Fleming2014-10-033-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are some circumstances that call for trying to write an EFI variable in a non-blocking way. One such scenario is when writing pstore data in efi_pstore_write() via the pstore_dump() kdump callback. Now that we have an EFI runtime spinlock we need a way of aborting if there is contention instead of spinning, since when writing pstore data from the kdump callback, the runtime lock may already be held by the CPU that's running the callback if we crashed in the middle of an EFI variable operation. The situation is sufficiently special that a new EFI variable operation is warranted. Introduce ->set_variable_nonblocking() for this use case. It is an optional EFI backend operation, and need only be implemented by those backends that usually acquire locks to serialize access to EFI variables, as is the case for virt_efi_set_variable() where we now grab the EFI runtime spinlock. Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
| | * | | | x86/efi: Adding efi_printks on memory allocationa and pci.readsAndre Müller2014-10-031-7/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All other calls to allocate memory seem to make some noise already, with the exception of two calls (for gop, uga) in the setup_graphics path. The purpose is to be noisy on worrysome errors immediately. commit fb86b2440de0 ("x86/efi: Add better error logging to EFI boot stub") introduces printing false alarms for lots of hardware. Rather than playing Whack a Mole with non-fatal exit conditions, try the other way round. This is per Matt Fleming's suggestion: > Where I think we could improve things > is by adding efi_printk() message in certain error paths. Clearly, not > all error paths need such messages, e.g. the EFI_INVALID_PARAMETER path > you highlighted above, but it makes sense for memory allocation and PCI > read failures. Link: http://article.gmane.org/gmane.linux.kernel.efi/4628 Signed-off-by: Andre Müller <andre.muller@web.de> Cc: Ulf Winkelvos <ulf@winkelvos.de> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
| | * | | | x86/efi: Mark initialization code as suchMathias Krause2014-10-035-22/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 32 bit and 64 bit implementations differ in their __init annotations for some functions referenced from the common EFI code. Namely, the 32 bit variant is missing some of the __init annotations the 64 bit variant has. To solve the colliding annotations, mark the corresponding functions in efi_32.c as initialization code, too -- as it is such. Actually, quite a few more functions are only used during initialization and therefore can be marked __init. They are therefore annotated, too. Also add the __init annotation to the prototypes in the efi.h header so users of those functions will see it's meant as initialization code only. This patch also fixes the "prelog" typo. ("prologue" / "epilogue" might be more appropriate but this is C code after all, not an opera! :D) Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
| | * | | | x86/efi: Update comment regarding required phys mapped EFI servicesMathias Krause2014-10-031-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 3f4a7836e331 ("x86/efi: Rip out phys_efi_get_time()") left set_virtual_address_map as the only runtime service needed with a phys mapping but missed to update the preceding comment. Fix that. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
| | * | | | x86/efi: Unexport add_efi_memmap variableMathias Krause2014-10-032-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This variable was accidentally exported, even though it's only used in this compilation unit and only during initialization. Remove the bogus export, make the variable static instead and mark it as __initdata. Fixes: 200001eb140e ("x86 boot: only pick up additional EFI memmap...") Cc: Paul Jackson <pj@sgi.com> Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
| | * | | | x86/efi: Remove unused efi_call* macrosMathias Krause2014-10-031-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Complement commit 62fa6e69a436 ("x86/efi: Delete most of the efi_call* macros") and delete the stub macros for the !CONFIG_EFI case, too. In fact, there are no EFI calls in this case so we don't need a dummy for efi_call() even. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>