summaryrefslogtreecommitdiff
path: root/drivers/hwmon/k10temp.c
AgeCommit message (Collapse)Author
2020-09-23hwmon: (k10temp) Add support for Zen3 CPUsWei Huang
Zen3 thermal info is supported via a new PCI device ID. Also the voltage telemetry registers and the current factors need to be defined. k10temp driver then searches for CPU family 0x19 and configures k10temp_data accordingly. Signed-off-by: Wei Huang <wei.huang2@amd.com> Link: https://lore.kernel.org/r/20200914200715.1997757-1-wei.huang2@amd.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-23hwmon: (k10temp) Take out debugfs codeGuenter Roeck
The debugfs code was intended to aid figuring out functionality of undocumented registers. Turns out that wasn't very helpful, since register locations change too much between AMD chip revisions, and the data isn't really valuable for chips where it isn't already supported. On top of that, its existence has been used as argument for providing pseudo-API debugfs functions in other drivers. So let's just take it out. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-23hwmon: (k10temp) Define SVI telemetry and current factors for Zen2 CPUsWei Huang
The voltage telemetry registers for Zen2 are different from Zen1. Also the factors of CPU current values are changed on Zen2. Add new definitions for these register. Signed-off-by: Wei Huang <wei.huang2@amd.com> Link: https://lore.kernel.org/r/20200827054242.2347-2-wei.huang2@amd.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-23hwmon: (k10temp) Create common functions and macros for Zen CPU familiesWei Huang
Many SMN thermal registers in Zen CPU families are common across different generations. For long-term code maintenance, it is better to rename these macro and function names to Zen. Signed-off-by: Wei Huang <wei.huang2@amd.com> Link: https://lore.kernel.org/r/20200827054242.2347-1-wei.huang2@amd.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-06-11Merge branch 'x86/entry' into ras/coreThomas Gleixner
to fixup conflicts in arch/x86/kernel/cpu/mce/core.c so MCE specific follow up patches can be applied without creating a horrible merge conflict afterwards.
2020-05-22hwmon: (k10temp) Add AMD family 17h model 60h PCI matchAlexander Monakov
Add support for retrieving Tdie and Tctl on AMD Renoir (4000-series Ryzen CPUs). It appears SMU offsets for reading current/voltage and CCD temperature have changed for this generation (reads from currently used offsets yield zeros), so those features cannot be enabled so trivially. Signed-off-by: Alexander Monakov <amonakov@ispras.ru> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Guenter Roeck <linux@roeck-us.net> Link: https://lkml.kernel.org/r/20200510204842.2603-3-amonakov@ispras.ru
2020-04-12hwmon: (k10temp) make some symbols staticJason Yan
Fix the following sparse warning: drivers/hwmon/k10temp.c:189:12: warning: symbol 'k10temp_temp_label' was not declared. Should it be static? drivers/hwmon/k10temp.c:202:12: warning: symbol 'k10temp_in_label' was not declared. Should it be static? drivers/hwmon/k10temp.c:207:12: warning: symbol 'k10temp_curr_label' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200409084502.42126-1-yanaijie@huawei.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-08hwmon: (k10temp) Reorganize and simplify temperature support detectionGuenter Roeck
Use a bit map to describe if temperature channels are supported, and use it for all temperature channels. Use a separate flag, independent of Tdie support, to indicate if the system is running on a Ryzen CPU. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-08hwmon: (k10temp) Swap Tdie and Tctl on Family 17h CPUsGuenter Roeck
Traditionally, the temperature displayed by k10temp was Tctl. On Family 17h CPUs, Tdie was displayed instead. To reduce confusion, Tctl was added later as second temperature. This resulted in Tdie being reported as temp1_input, and Tctl as temp2_input. This is different to non-Ryzen CPUs, where Tctl is displayed as temp1_input. Swap temp1_input and temp2_input on Family 17h CPUs, such that Tctl is now reported as temp1_input and Tdie is reported as temp2_input, to align with other CPUs, streamline the code, and make it less confusing. Coincidentally, this also aligns the code with its documentation, which states that Tdie is reported as temp2_input. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-23hwmon: (k10temp) Display up to eight sets of CCD temperaturesGuenter Roeck
In HWiNFO, we see support for Tccd1, Tccd3, Tccd5, and Tccd7 temperature sensors on Zen2 based Threadripper CPUs. Checking register maps on Threadripper 3970X confirms SMN register addresses and values for those sensors. Register values observed in an idle system: 0x059950: 00000000 00000abc 00000000 00000ad8 0x059960: 00000000 00000ade 00000000 00000ae4 Under load: 0x059950: 00000000 00000c02 00000000 00000c14 0x059960: 00000000 00000c30 00000000 00000c22 More analysis shows that EPYC CPUs support up to 8 CCD temperature sensors. EPYC 7601 supports three CCD temperature sensors. Unlike Zen2 CPUs, the register space in Zen1 CPUs supports a maximum of four sensors, so only search for a maximum of four sensors on Zen1 CPUs. On top of that, in thm_10_0_sh_mask.h in the Linux kernel, we find definitions for THM_DIE{1-3}_TEMP__VALID_MASK, set to 0x00000800, as well as matching SMN addresses. This lets us conclude that bit 11 of the respective registers is a valid bit. With this assumption, the temperature offset is now 49 degrees C. This conveniently matches the documented temperature offset for Tdie, again suggesting that above registers indeed report temperatures sensor values. Assume that bit 11 is indeed a valid bit, and add support for the additional sensors. With this patch applied, output from 3970X (idle) looks as follows: k10temp-pci-00c3 Adapter: PCI adapter Tdie: +55.9°C Tctl: +55.9°C Tccd1: +39.8°C Tccd3: +43.8°C Tccd5: +43.8°C Tccd7: +44.8°C Tested-by: Michael Larabel <michael@phoronix.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-23hwmon: (k10temp) Add debugfs supportGuenter Roeck
Show thermal and SVI registers for Family 17h CPUs. Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-23hwmon: (k10temp) Don't show temperature limits on Ryzen (Zen) CPUsGuenter Roeck
The maximum Tdie or Tctl is not published for Ryzen CPUs. What is known, however, is that the traditional value of 70 degrees C is no longer correct. On top of that, the limit applies to Tctl, not to Tdie. Displaying it in either context is meaningless, confusing, and wrong. Stop doing it. Tested-by: Brad Campbell <lists2009@fnarfbargle.com> Tested-by: Holger Kiehl <holger.kiehl@dwd.de> Tested-by: Michael Larabel <michael@phoronix.com> Tested-by: Jonathan McDowell <noodles@earth.li> Tested-by: Ken Moffat <zarniwhoop73@googlemail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-23hwmon: (k10temp) Show core and SoC current and voltages on Ryzen CPUsGuenter Roeck
Ryzen CPUs report core and SoC voltages and currents. Add support for it to the k10temp driver. For the time being, only report voltages and currents for Ryzen CPUs. Threadripper and EPYC appear to use a different mechanism. Tested-by: Brad Campbell <lists2009@fnarfbargle.com> Tested-by: Bernhard Gebetsberger <bernhard.gebetsberger@gmx.at> Tested-by: Holger Kiehl <holger.kiehl@dwd.de> Tested-by: Michael Larabel <michael@phoronix.com> Tested-by: Jonathan McDowell <noodles@earth.li> Tested-by: Ken Moffat <zarniwhoop73@googlemail.com> Tested-by: Darren Salt <devspam@moreofthesa.me.uk> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-23hwmon: (k10temp) Report temperatures per CPU dieGuenter Roeck
Zen2 reports reporting temperatures per CPU die (called Core Complex Dies, or CCD, by AMD). Add support for it to the k10temp driver. Tested-by: Brad Campbell <lists2009@fnarfbargle.com> Tested-by: Bernhard Gebetsberger <bernhard.gebetsberger@gmx.at> Tested-by: Holger Kiehl <holger.kiehl@dwd.de> Tested-by: Michael Larabel <michael@phoronix.com> Tested-by: Jonathan McDowell <noodles@earth.li> Tested-by: Ken Moffat <zarniwhoop73@googlemail.com> Tested-by: Darren Salt <devspam@moreofthesa.me.uk> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-23hmon: (k10temp) Convert to use devm_hwmon_device_register_with_infoGuenter Roeck
Convert driver to use devm_hwmon_device_register_with_info to simplify the code and to reduce its size. Old size (x86_64): text data bss dec hex filename 8247 4488 64 12799 31ff drivers/hwmon/k10temp.o New size: text data bss dec hex filename 6778 2792 64 9634 25a2 drivers/hwmon/k10temp.o Tested-by: Brad Campbell <lists2009@fnarfbargle.com> Tested-by: Bernhard Gebetsberger <bernhard.gebetsberger@gmx.at> Tested-by: Holger Kiehl <holger.kiehl@dwd.de> Tested-by: Michael Larabel <michael@phoronix.com> Tested-by: Jonathan McDowell <noodles@earth.li> Tested-by: Ken Moffat <zarniwhoop73@googlemail.com> Tested-by: Darren Salt <devspam@moreofthesa.me.uk> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-23hwmon: (k10temp) Use bitopsGuenter Roeck
Using bitops makes bit masks and shifts easier to read. Tested-by: Brad Campbell <lists2009@fnarfbargle.com> Tested-by: Bernhard Gebetsberger <bernhard.gebetsberger@gmx.at> Tested-by: Holger Kiehl <holger.kiehl@dwd.de> Tested-by: Michael Larabel <michael@phoronix.com> Tested-by: Jonathan McDowell <noodles@earth.li> Tested-by: Ken Moffat <zarniwhoop73@googlemail.com> Tested-by: Darren Salt <devspam@moreofthesa.me.uk> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2019-09-03hwmon: (k10temp) Add support for AMD family 17h, model 70h CPUsMarcel Bocu
It would seem like model 70h is behaving in the same way as model 30h, so let's just add the new F3 PCI ID to the list of compatible devices. Unlike previous Ryzen/Threadripper, Ryzen gen 3 processors do not need temperature offsets anymore. This has been reported in the press and verified on my Ryzen 3700X by checking that the idle temperature reported by k10temp is matching the temperature reported by the firmware. Vicki Pfau sent an identical patch after I checked that no-one had written this patch. I would have been happy about dropping my patch but unlike for his patch series, I had already Cc:ed the x86 people and they already reviewed the changes. Since Vicki has not answered to any email after his initial series, let's assume she is on vacation and let's avoid duplication of reviews from the maintainers and merge my series. To acknowledge Vicki's anteriority, I added her S-o-b to the patch. v2, suggested by Guenter Roeck and Brian Woods: - rename from 71h to 70h Signed-off-by: Vicki Pfau <vi@endrift.com> Signed-off-by: Marcel Bocu <marcel.p.bocu@gmail.com> Tested-by: Marcel Bocu <marcel.p.bocu@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Cc: "Woods, Brian" <Brian.Woods@amd.com> Cc: Clemens Ladisch <clemens@ladisch.de> Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-hwmon@vger.kernel.org Link: https://lore.kernel.org/r/20190722174653.2391-1-marcel.p.bocu@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2019-05-24treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 56Thomas Gleixner
Based on 1 normalized pattern(s): this driver is free software you can redistribute it and or modify it under the terms of the gnu general public license either version 2 of the license or at your option any later version this driver is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this driver if not see http www gnu org licenses extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 2 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190520071858.296418152@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-28Merge tag 'hwmon-for-v4.21' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon updates from Guenter Roeck: "The big change in this series is for the most part automatic: Introducing SENSOR[_DEVICE]_ATTR_{RO,RW,WO} variants and conversion of various drivers to use it. This is similar to DEVICE_ATTR variants. Other than that, we have - Some conversions of S_<PERMS> with octal values, also automated - Added support for Hygon Dhyana CPUs to k10temp driver - Added support for STLM75 to lm75 driver - B57891S0103 to ntc_thermistor - Added pm-runtime support to ina3221 driver - Support for PowerPC On-Chip Controller (OCC) - Various minor bug fices and improvements" * tag 'hwmon-for-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (80 commits) hwmon: (lm80) fix a missing check of bus read in lm80 probe hwmon: (lm80) fix a missing check of the status of SMBus read hwmon: (asus_atk0110) Fix debugfs_simple_attr.cocci warnings hwmon: (ftsteutates) Use permission specific SENSOR[_DEVICE]_ATTR variants hwmon: (fschmd) Use permission specific SENSOR[_DEVICE]_ATTR variants hwmon: (emc6w201) Use permission specific SENSOR[_DEVICE]_ATTR variants hwmon: (emc2103) Use permission specific SENSOR[_DEVICE]_ATTR variants hwmon: (emc1403) Use permission specific SENSOR[_DEVICE]_ATTR variants hwmon: (ds620) Use permission specific SENSOR[_DEVICE]_ATTR variants hwmon: (ds1621) Use permission specific SENSOR[_DEVICE]_ATTR variants hwmon: (dell-smm-hwmon) Use permission specific SENSOR[_DEVICE]_ATTR variants hwmon: (da9055-hwmon) Use permission specific SENSOR[_DEVICE]_ATTR variants hwmon: (da9052-hwmon) Use permission specific SENSOR[_DEVICE]_ATTR variants hwmon: (coretemp) Replace S_<PERMS> with octal values hwmon: (asus_atk0110) Replace S_<PERMS> with octal values hwmon: (aspeed-pwm-tacho) Use permission specific SENSOR[_DEVICE]_ATTR variants hwmon: (applesmc) Replace S_<PERMS> with octal values hwmon: (amc6821) Use permission specific SENSOR[_DEVICE]_ATTR variants hwmon: (adt7x10) Use permission specific SENSOR[_DEVICE]_ATTR variants hwmon: (adt7475) Use permission specific SENSOR[_DEVICE]_ATTR variants ...
2018-12-16hwmon: (k10temp) Add Hygon Dhyana supportPu Wen
Add support for Hygon Dhyana family 18h processor for k10temp to get the temperature. As Hygon Dhyana shares the same function interface with AMD family 17h, so add Hygon PCI Vendor ID and reuse the code path of AMD. Signed-off-by: Pu Wen <puwen@hygon.cn> Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-12-16hwmon: (k10temp) Auto-convert to use SENSOR_DEVICE_ATTR_{RO, RW, WO}Guenter Roeck
Auto-conversion was done done using the coccinelle script at https://github.com/groeck/coccinelle-patches/blob/master/hwmon/sensor-devattr-w6.cocci Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-11-07hwmon/k10temp: Add support for AMD family 17h, model 30h CPUsWoods, Brian
Add support for AMD family 17h model 30h processors for k10temp. Model 30h is functionally the same as model 01h processors (as far as k10temp is concerned), just the PCI device IDs need to be updated. Signed-off-by: Brian Woods <brian.woods@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Guenter Roeck <linux@roeck-us.net> CC: Bjorn Helgaas <bhelgaas@google.com> CC: Clemens Ladisch <clemens@ladisch.de> CC: "H. Peter Anvin" <hpa@zytor.com> CC: Ingo Molnar <mingo@redhat.com> CC: Jean Delvare <jdelvare@suse.com> CC: Jia Zhang <qianyue.zj@alibaba-inc.com> CC: <linux-hwmon@vger.kernel.org> CC: <linux-pci@vger.kernel.org> CC: Pu Wen <puwen@hygon.cn> CC: Thomas Gleixner <tglx@linutronix.de> CC: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/20181106200754.60722-5-brian.woods@amd.com
2018-11-07hwmon/k10temp, x86/amd_nb: Consolidate shared device IDsWoods, Brian
Consolidate shared PCI_DEVICE_IDs that were scattered through k10temp and amd_nb, and move them into pci_ids. Signed-off-by: Brian Woods <brian.woods@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Guenter Roeck <linux@roeck-us.net> CC: Bjorn Helgaas <bhelgaas@google.com> CC: Clemens Ladisch <clemens@ladisch.de> CC: "H. Peter Anvin" <hpa@zytor.com> CC: Ingo Molnar <mingo@redhat.com> CC: Jean Delvare <jdelvare@suse.com> CC: Jia Zhang <qianyue.zj@alibaba-inc.com> CC: <linux-hwmon@vger.kernel.org> CC: <linux-pci@vger.kernel.org> CC: Pu Wen <puwen@hygon.cn> CC: Thomas Gleixner <tglx@linutronix.de> CC: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/20181106200754.60722-2-brian.woods@amd.com
2018-10-10hwmon: (k10temp) Support all Family 15h Model 6xh and Model 7xh processorsGuenter Roeck
BIOS developer guides refer to Family 15h Models 60h-6fh and Family 15h Models 70h-7fh. So far the driver only checked for Models 60h and 70h. However, there are now processors with other model numbers in the same families. Example is A10-9620P family 15h model 65h. Follow the developer guides and mask the lower 4 bit of the model number to determine the registers to use for reading temperatures and temperature limits. Reported-by: Guglielmo Fanini <g.fanini@gmail.com> Cc: Guglielmo Fanini <g.fanini@gmail.com> Acked-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-08-09hwmon: k10temp: Support Threadripper 2920X, 2970WX; simplify offset tableGuenter Roeck
All announced Threadripper 29xx models have a temperature offset of 27 degrees C. Simplify temperature offset table to match all 29xx Threadripper models with a single entry. Also simplify the table to match all 19xx Threadripper models with a single entry. This effectively drops entries for Threadripper 1910/1920/1950 which never saw the light of day. Cc: Michael Larabel <Michael@phoronix.com> Cc: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-08-07hwmon: (k10temp) 27C Offset needed for Threadripper2Michael Larabel
For at least the Threadripper 2950X and Threadripper 2990WX, it's confirmed a 27 degree offset is needed. Signed-off-by: Michael Larabel <michael@phoronix.com> Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-06-01hwmon: (k10temp) Make function get_raw_temp staticColin Ian King
The function get_raw_temp is local to the source and does not need to be in global scope, so make it static. Cleans up sparse warning: drivers/hwmon/k10temp.c:149:14: warning: symbol 'get_raw_temp' was not declared. Should it be static? Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-05-21hwmon: (k10temp) Display both Tctl and TdieGuenter Roeck
On some AMD CPUs, there is a different between the die temperature (Tdie) and the reported temperature (Tctl). Tdie is the real measured temperature, and Tctl is used for fan control. Lets report both for affected CPUs. Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-05-21hwmon: (k10temp) Add support for Stoney Ridge and Bristol Ridge CPUsGuenter Roeck
Add support for Stoney Ridge and Bristol Ridge (Family 15h Model 0x70) CPUs. Registers match those of Family 15h Model 0x60. Cc: stable@vger.kernel.org # v4.16+ Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-05-13hwmon: (k10temp) Use API function to access System Management NetworkGuenter Roeck
The SMN (System Management Network) on Family 17h AMD CPUs is also accessed from other drivers, specifically EDAC. Accessing it directly is racy. On top of that, accessing the SMN through root bridge 00:00 is wrong on multi-die CPUs and may result in reading the temperature from the wrong die. Use available API functions to fix the problem. For this to work, add dependency on AMD_NB. Also change the Raven Ridge PCI device ID to point to Data Fabric Function 3, since this ID is used by the API functions to find the CPU node. Cc: stable@vger.kernel.org # v4.16+ Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-04-29hwmon: (k10temp) Fix reading critical temperature registerGuenter Roeck
The HTC (Hardware Temperature Control) register has moved for recent chips. Cc: stable@vger.kernel.org # v4.16+ Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-04-25hwmon: (k10temp) Add support for AMD Ryzen w/ Vega graphicsGuenter Roeck
Enable k10temp for AMD Ryzen APUs w/ Vega Mobile Gfx. Based on patch from René Rebe <rene@exactcode.de>. Dropped temperature offsets since those are not supposed to apply for the affected CPUs. Cc: stable@vger.kernel.org # v4.16+ Cc: René Rebe <rene@exactcode.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-04-25hwmon: (k10temp) Add temperature offset for Ryzen 2700XGuenter Roeck
Ryzen 2700X has a temperature offset of 10 degrees C. If bit 19 of the Temperature Control register is set, there is an additional offset of 49 degrees C. Take this into account as well. Cc: stable@vger.kernel.org # v4.16+ Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-02-15Merge tag 'hwmon-for-linus-v4.16-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fix from Guenter Roeck: "Fix bad temperature display on Ryzen/Threadripper" * tag 'hwmon-for-linus-v4.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (k10temp) Only apply temperature offset if result is positive
2018-02-14Merge branch 'x86-pti-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 PTI and Spectre related fixes and updates from Ingo Molnar: "Here's the latest set of Spectre and PTI related fixes and updates: Spectre: - Add entry code register clearing to reduce the Spectre attack surface - Update the Spectre microcode blacklist - Inline the KVM Spectre helpers to get close to v4.14 performance again. - Fix indirect_branch_prediction_barrier() - Fix/improve Spectre related kernel messages - Fix array_index_nospec_mask() asm constraint - KVM: fix two MSR handling bugs PTI: - Fix a paranoid entry PTI CR3 handling bug - Fix comments objtool: - Fix paranoid_entry() frame pointer warning - Annotate WARN()-related UD2 as reachable - Various fixes - Add Add Peter Zijlstra as objtool co-maintainer Misc: - Various x86 entry code self-test fixes - Improve/simplify entry code stack frame generation and handling after recent heavy-handed PTI and Spectre changes. (There's two more WIP improvements expected here.) - Type fix for cache entries There's also some low risk non-fix changes I've included in this branch to reduce backporting conflicts: - rename a confusing x86_cpu field name - de-obfuscate the naming of single-TLB flushing primitives" * 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (41 commits) x86/entry/64: Fix CR3 restore in paranoid_exit() x86/cpu: Change type of x86_cache_size variable to unsigned int x86/spectre: Fix an error message x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping selftests/x86/mpx: Fix incorrect bounds with old _sigfault x86/mm: Rename flush_tlb_single() and flush_tlb_one() to __flush_tlb_one_[user|kernel]() x86/speculation: Add <asm/msr-index.h> dependency nospec: Move array_index_nospec() parameter checking into separate macro x86/speculation: Fix up array_index_nospec_mask() asm constraint x86/debug: Use UD2 for WARN() x86/debug, objtool: Annotate WARN()-related UD2 as reachable objtool: Fix segfault in ignore_unreachable_insn() selftests/x86: Disable tests requiring 32-bit support on pure 64-bit systems selftests/x86: Do not rely on "int $0x80" in single_step_syscall.c selftests/x86: Do not rely on "int $0x80" in test_mremap_vdso.c selftests/x86: Fix build bug caused by the 5lvl test which has been moved to the VM directory selftests/x86/pkeys: Remove unused functions selftests/x86: Clean up and document sscanf() usage selftests/x86: Fix vDSO selftest segfault for vsyscall=none x86/entry/64: Remove the unused 'icebp' macro ...
2018-02-15x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_steppingJia Zhang
x86_mask is a confusing name which is hard to associate with the processor's stepping. Additionally, correct an indent issue in lib/cpu.c. Signed-off-by: Jia Zhang <qianyue.zj@alibaba-inc.com> [ Updated it to more recent kernels. ] Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bp@alien8.de Cc: tony.luck@intel.com Link: http://lkml.kernel.org/r/1514771530-70829-1-git-send-email-qianyue.zj@alibaba-inc.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-12hwmon: (k10temp) Only apply temperature offset if result is positiveGuenter Roeck
A user reports a really bad temperature on Ryzen 1950X. k10temp-pci-00cb Adapter: PCI adapter temp1: +4294948.3°C (high = +70.0°C) This will happen if the temperature reported by the chip is lower than the offset temperature. This has been seen in the field if "Sense MI Skew" and/or "Sense MI Offset" BIOS parameters were set to unexpected values. Let's report a temperature of 0 degrees C in that case. Fixes: 1b50b776355f ("hwmon: (k10temp) Add support for temperature offsets") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-19hwmon: (k10temp) Add temperature offset for Ryzen 1900XGuenter Roeck
Like the other CPUs from the same series, the 1900X has a temperature offset of 27 degrees C. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-11-16hwmon: (k10temp) Correct model name for Ryzen 1600XGuenter Roeck
Ryzen 1600X is a Ryzen 5 processor. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-10-29hwmon: (k10temp) Add support for temperature offsetsGuenter Roeck
Add support for handling temperature offset values for various AMD CPUs, similar to the code used in the coretemp driver for Intel CPUs. This is primarily for Ryzen CPUs (which has documented temperature offsets), but the code is kept generic to simplify adding additional CPUs. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-10-29hwmon: (k10temp) Add support for family 17hGuenter Roeck
Add support for temperature sensors on Family 17h (Ryzen) processors. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-10-29hwmon: (k10temp) Move chip specific code into probe functionGuenter Roeck
Introduce a local data structure and determine the temperature read function at probe time to reduce runtime complexity. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-01-02hwmon: (k10temp) use permission-specific DEVICE_ATTR variantsJulia Lawall
Use DEVICE_ATTR_RO for read-only attributes. This simplifies the source code, improves readbility, and reduces the chance of inconsistencies. The conversion was done automatically using coccinelle. It was validated by compiling both the old and the new source code and comparing its text, data, and bss size. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> [groeck: Updated description] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-11-09hwmon: (k10temp) Remove duplicate pci-id defineAdam Majer
PCI_DEVICE_ID_AMD_15H_M60H_NB_F3 is now defined in pci_ids.h Signed-off-by: Adam Majer <adamm@zombino.com> Acked-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Jean Delvare <jdelvare@suse.de>
2014-09-22hwmon: (k10temp) Convert to devm_hwmon_device_register_with_groupsGuenter Roeck
Use devm_hwmon_device_register_with_groups() to simplify the code and reduce code size. Cc: Clemens Ladisch <clemens@ladisch.de> Tested-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2014-09-22hwmon: (k10temp) Add support for F15h M60hAravind Gopalakrishnan
This patch adds temperature monitoring support for F15h M60h processor. - Add new pci device id for the relevant processor - The functionality of REG_REPORTED_TEMPERATURE is moved to D0F0xBC_xD820_0CA4 [Reported Temperature Control] - So, use this to get CUR_TEMP value - Since we need an indirect register access, protect this with a mutex lock - Add Kconfig, Doc entries to indicate support for this processor. Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com> Acked-by: Borislav Petkov <bp@suse.de> Acked-by: Clemens Ladisch <clemens@ladisch.de> [Guenter Roeck: Declare new mutex and function static] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2014-04-02hwmon: (k10temp) Add support for AMD F16 M30h processorAravind Gopalakrishnan
Adding new PCI ID to support AMD F16 M30h processor (Mullins). While at it, modify Kconfig and Doc files to reflect the support for newer processors Note: PCI ID for this processor will make it into pci_ids.h as part of this patch: http://marc.info/?l=linux-kernel&m=139291362126057&w=2 which should be pulled into 3.15 when merge window opens (It currently sits in 'for-next' branch of bp.git- https://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/log/?h=for-next) Signed-off-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2014-01-14hwmon: (k10temp) Add support for Kaveri CPUsPhil Pokorny
Add new PCI ID to support new model "Kaveri" family. Signed-off-by: Philip Pokorny <ppokorny@penguincomputing.com> Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2014-01-14hwmon: remove DEFINE_PCI_DEVICE_TABLE macroJingoo Han
Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro is not preferred. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2013-09-12hwmon: (k10temp) remove unnecessary pci_set_drvdata()Jingoo Han
The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>