Commit id "b00647c4",
adds reporting current and voltage to k10temp.c

The commit id "0a4e668b",
removed reporting current and voltage from k10temp.c

The curr and in(voltage) entries are not removed from
"k10temp_info" structure. Removing those residue entries.
while at it, update k10temp driver documentation
Signed-off-by: Nsuma hegde <suma.hegde@amd.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20210902174155.7365-2-nchatrad@amd.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

Yellow carp matches same behavior as green sardine and other Zen3
products, but have different CCD offsets.
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20210827201527.24454-3-mario.limonciello@amd.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

Some of the existing assumptions made do not scale properly
to new silicon in upcoming changes.  This commit should cause
no functional changes to existing silicon.
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20210827201527.24454-2-mario.limonciello@amd.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

Tdie is an offset calculation that should only be shown when temp_offset
is actually put into a table.  This is useless to show for all CPU/APU.
Show it only when necessary.
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

These follow the rest of the existing codepaths for families
17h and 19h.
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Add support for Zen3 Ryzen APU.
Signed-off-by: NDavid Bartley <andareed@gmail.com>
Link: https://lore.kernel.org/r/20210517064131.4369-1-andareed@gmail.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

The module has only support for Zen3 server CPUs right now.
Add support for Family 0x19, model 0x21 which are Zen3 Ryzen Desktop CPUs.
Tested on 5800x, 5900x and 5950x CPUs.
Signed-off-by: NGabriel Craciunescu <nix.or.die@gmail.com>
Link: https://lore.kernel.org/r/20201223005315.20077-1-nix.or.die@gmail.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

Voltages and current are reported by Zen CPUs. However, the means
to do so is undocumented, changes from CPU to CPU, and the raw data
is not calibrated. Calibration information is available, but again
not documented. This results in less than perfect user experience,
up to concerns that loading the driver might possibly damage
the hardware (by reporting out-of range voltages). Effectively
support for reporting voltages and current is not maintainable.
Drop it.

Cc: Artem S. Tashkinov <aros@gmx.com>
Cc: Wei Huang <wei.huang2@amd.com>
Tested-by: NWei Huang <wei.huang2@amd.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NWei Huang <wei.huang2@amd.com>
Link: https://lore.kernel.org/r/20200914200715.1997757-1-wei.huang2@amd.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NGuenter Roeck <linux@roeck-us.net>

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: NWei Huang <wei.huang2@amd.com>
Link: https://lore.kernel.org/r/20200827054242.2347-2-wei.huang2@amd.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NWei Huang <wei.huang2@amd.com>
Link: https://lore.kernel.org/r/20200827054242.2347-1-wei.huang2@amd.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NAlexander Monakov <amonakov@ispras.ru>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Link: https://lkml.kernel.org/r/20200510204842.2603-3-amonakov@ispras.ru

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: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200409084502.42126-1-yanaijie@huawei.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NGuenter Roeck <linux@roeck-us.net>

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: NGuenter Roeck <linux@roeck-us.net>

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: NMichael Larabel <michael@phoronix.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Show thermal and SVI registers for Family 17h CPUs.
Tested-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NBrad Campbell <lists2009@fnarfbargle.com>
Tested-by: NHolger Kiehl <holger.kiehl@dwd.de>
Tested-by: NMichael Larabel <michael@phoronix.com>
Tested-by: NJonathan McDowell <noodles@earth.li>
Tested-by: NKen Moffat <zarniwhoop73@googlemail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NBrad Campbell <lists2009@fnarfbargle.com>
Tested-by: NBernhard Gebetsberger <bernhard.gebetsberger@gmx.at>
Tested-by: NHolger Kiehl <holger.kiehl@dwd.de>
Tested-by: NMichael Larabel <michael@phoronix.com>
Tested-by: NJonathan McDowell <noodles@earth.li>
Tested-by: NKen Moffat <zarniwhoop73@googlemail.com>
Tested-by: NDarren Salt <devspam@moreofthesa.me.uk>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NBrad Campbell <lists2009@fnarfbargle.com>
Tested-by: NBernhard Gebetsberger <bernhard.gebetsberger@gmx.at>
Tested-by: NHolger Kiehl <holger.kiehl@dwd.de>
Tested-by: NMichael Larabel <michael@phoronix.com>
Tested-by: NJonathan McDowell <noodles@earth.li>
Tested-by: NKen Moffat <zarniwhoop73@googlemail.com>
Tested-by: NDarren Salt <devspam@moreofthesa.me.uk>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NBrad Campbell <lists2009@fnarfbargle.com>
Tested-by: NBernhard Gebetsberger <bernhard.gebetsberger@gmx.at>
Tested-by: NHolger Kiehl <holger.kiehl@dwd.de>
Tested-by: NMichael Larabel <michael@phoronix.com>
Tested-by: NJonathan McDowell <noodles@earth.li>
Tested-by: NKen Moffat <zarniwhoop73@googlemail.com>
Tested-by: NDarren Salt <devspam@moreofthesa.me.uk>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Using bitops makes bit masks and shifts easier to read.
Tested-by: NBrad Campbell <lists2009@fnarfbargle.com>
Tested-by: NBernhard Gebetsberger <bernhard.gebetsberger@gmx.at>
Tested-by: NHolger Kiehl <holger.kiehl@dwd.de>
Tested-by: NMichael Larabel <michael@phoronix.com>
Tested-by: NJonathan McDowell <noodles@earth.li>
Tested-by: NKen Moffat <zarniwhoop73@googlemail.com>
Tested-by: NDarren Salt <devspam@moreofthesa.me.uk>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NVicki Pfau <vi@endrift.com>
Signed-off-by: NMarcel Bocu <marcel.p.bocu@gmail.com>
Tested-by: NMarcel 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.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NRichard Fontana <rfontana@redhat.com>
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190520071858.296418152@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NPu Wen <puwen@hygon.cn>
Acked-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Auto-conversion was done done using the coccinelle script at
https://github.com/groeck/coccinelle-patches/blob/master/hwmon/sensor-devattr-w6.cocciSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NBrian Woods <brian.woods@amd.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: NGuenter 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

Consolidate shared PCI_DEVICE_IDs that were scattered through k10temp
and amd_nb, and move them into pci_ids.
Signed-off-by: NBrian Woods <brian.woods@amd.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: NGuenter 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

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: NGuglielmo Fanini <g.fanini@gmail.com>
Cc: Guglielmo Fanini <g.fanini@gmail.com>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NGuenter Roeck <linux@roeck-us.net>

For at least the Threadripper 2950X and Threadripper 2990WX,
it's confirmed a 27 degree offset is needed.
Signed-off-by: NMichael Larabel <michael@phoronix.com>
Cc: stable@vger.kernel.org
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NGabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NGabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NGabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

The HTC (Hardware Temperature Control) register has moved
for recent chips.

Cc: stable@vger.kernel.org # v4.16+
Tested-by: NGabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NGuenter Roeck <linux@roeck-us.net>

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: NGuenter Roeck <linux@roeck-us.net>

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: NJia 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.comSigned-off-by: NIngo Molnar <mingo@kernel.org>