The driver is superceeded by asus-ec-sensors

Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>

Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>

This driver provides the same data as the asus_wmi_ec_sensors driver
(and gets it from the same source) but does not use WMI, polling
the ACPI EC directly.

That provides two enhancements: sensor reading became quicker (on some
systems or kernel configuration it took almost a full second to read
all the sensors, that transfers less than 15 bytes of data), the driver
became more flexible. The driver now relies on ACPI mutex to lock access
to the EC in the same way as the WMI code does.

Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>

This moves the device tree match data toward the end of the
driver which is the convention, here we can also add ACPI
and similar match data in a conforming manner.

Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211205235948.4167075-3-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

This switches to retrieveing the configuration of the NTC
from generic firmware properties so that we get neutral from
device tree: now ACPI or, more importantly, software nodes
can be used to spawn NTC devices provided they have the
required properties.

This was inspired by the similar changes made to the IIO
drivers.

This was tested on the Ux500 HREF with the NTC devices
probing from device tree just as fine after this as before.

Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211206020423.62402-2-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Move the parsing of the DT config right above probe().

Allocate the state container for the driver in probe()
instead of inside the DT config parsing function: as a
result return an int instead of a pointer.

Drop the check for !np: we can only probe from DT right
now so no risk of ending up here.

Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211206020423.62402-1-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Variable range is being initialized with a value that is never read, it
is being re-assigned in the next statement. The assignment is redundant,
remove it and initialize range using the second assigned value. Clean up
the formatting too by adding missing spaces.

Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20211204233155.55454-1-colin.i.king@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Smatch detects this array overflow:

    drivers/hwmon/asus_wmi_sensors.c:569 asus_wmi_configure_sensor_setup()
    error: buffer overflow 'hwmon_attributes' 8 <= 9

The hwmon_attributes[] array should have "hwmon_max" so that it gets
larger when more attributes are added.

Fixes: 9d07e54 ("hwmon: (asus_wmi_sensors) Support X370 Asus WMI.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211130105117.GH5827@kili
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Smatch detected an array out of bounds error:

    drivers/hwmon/asus_wmi_ec_sensors.c:562 asus_wmi_ec_configure_sensor_setup()
    error: buffer overflow 'hwmon_attributes' 8 <= 9

The hwmon_attributes[] array needs to be declared with "hwmon_max"
elements.

Fixes: c04c7f7 ("hwmon: (asus_wmi_ec_sensors) Support B550 Asus WMI.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211130105034.GG5827@kili
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

This patch enables automatic loading of the sht4x module via a device
tree table entry.

Signed-off-by: David Mosberger-Tang <davidm@egauge.net>
Link: https://lore.kernel.org/r/20211121160637.2312106-1-davidm@egauge.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Allocate one state container for the device: struct ntc_data.
Move all items from struct ntc_thermistor_platform_data into
this struct and simplify.

Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211125020841.3616359-5-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

The only possible assignment of a function to get a voltage to
convert to a resistance is to use the internal function
ntc_adc_iio_read() which is only available when using IIO
and OF.

Bite the bullet and mandate OF and IIO, drop the read_uv()
callback abstraction and some ifdefs.

As no board is using the platform data, all users are using
OF and IIO anyway.

Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211125020841.3616359-4-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Nothing in the kernel (this driver) is using the callback to
read ohms directly. We always read a voltage and convert it
to a resistance. Drop this callback.

Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211125020841.3616359-3-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Platform data is supposed to be used with "board files",
device descriptions in C. Since the introduction of the
NTC driver in 2011, no such platforms have been submitted
to the Linux kernel, and their use is strongly discouraged
in favor of Device Tree, ACPI or as last resort software
firmware nodes.

Drop the external header and copy the platform data into
the driver file.

Cc: Peter Rosin <peda@axentia.se>
Cc: Chris Lesiak <chris.lesiak@licor.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211125020841.3616359-2-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

N34TS04 is a JC42.4 compatible temperature sensor from ONSEMI.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>

The current driver can read the temperatures from upto 8 CCDs
(Core-Complex Die).

The newer AMD Family 19h Models 10h-1Fh and A0h-AFh can support up to
12 CCDs. Update the driver to read up to 12 CCDs.

Signed-off-by: Babu Moger <babu.moger@amd.com>
Link: https://lore.kernel.org/r/163776976762.904164.5618896687524494215.stgit@bmoger-ubuntu
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Provides a Linux kernel module "asus_wmi_sensors" that provides sensor
readouts via ASUS' WMI interface present in the UEFI of
X370/X470/B450/X399 Ryzen motherboards.

Supported motherboards:
* ROG CROSSHAIR VI HERO,
* PRIME X399-A,
* PRIME X470-PRO,
* ROG CROSSHAIR VI EXTREME,
* ROG CROSSHAIR VI HERO (WI-FI AC),
* ROG CROSSHAIR VII HERO,
* ROG CROSSHAIR VII HERO (WI-FI),
* ROG STRIX B450-E GAMING,
* ROG STRIX B450-F GAMING,
* ROG STRIX B450-I GAMING,
* ROG STRIX X399-E GAMING,
* ROG STRIX X470-F GAMING,
* ROG STRIX X470-I GAMING,
* ROG ZENITH EXTREME,
* ROG ZENITH EXTREME ALPHA.

Co-developed-by: Ed Brindley <kernel@maidavale.org>
Signed-off-by: Ed Brindley <kernel@maidavale.org>
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
[groeck: Squashed:
 "hwmon: Fix warnings in asus_wmi_sensors.rst documetation."]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Linux HWMON sensors driver for ASUS motherboards to read
sensors from the embedded controller.

Many ASUS motherboards do not publish all the available
sensors via the Super I/O chip but the missing ones are
available through the embedded controller (EC) registers.

This driver implements reading those sensor data via the
WMI method BREC, which is known to be present in all ASUS
motherboards based on the AMD 500 series chipsets (and
probably is available in other models too). The driver
needs to know exact register addresses for the sensors and
thus support for each motherboard has to be added explicitly.

The EC registers do not provide critical values for the
sensors and as such they are not published to the HWMON.

Supported motherboards:
* PRIME X570-PRO
* Pro WS X570-ACE
* ROG CROSSHAIR VIII HERO
* ROG CROSSHAIR VIII DARK HERO
* ROG CROSSHAIR VIII FORMULA
* ROG STRIX X570-E GAMING
* ROG STRIX B550-I GAMING
* ROG STRIX B550-E GAMING

Co-developed-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Co-developed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
Tested-by: Tor Vic <torvic9@mailbox.org>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

This adds hardware monitor support the Fintek F81966 Super I/O chip.
Testing was done on the Aaeon SSE-IPTI

Signed-off-by: Menghui Wu <Menghui_Wu@aaeon.com.tw>
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Link: https://lore.kernel.org/r/20211117024320.2428144-1-acelan.kao@canonical.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

The adm1021 driver is quite generous with its automatic chip detection
and easily misdetects several chips. Strengthen detection of MAX1617,
MAX1617A, and LM84 to make the driver less vulnerable to false matches.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Since we are using regmap access functions to write into chip registers,
we can hide the difference in register write addresses within regmap
code. By doing this we do not need to clear the regmap cache on register
writes, and the high level code does not need to bother about different
read/write register addresses.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Use regmap for register accesses to be able to utilize its caching
functionality. This also lets us hide register access differences
in regmap code.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>

The new API is cleaner and reduces code size significantly.
All chip accesses are 'hidden' in chip access to prepare for using
regmap. Local caching code is removed, to be replaced by regmap based
caching in a follow-up patch.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>

The difference between TMP431 and other chips of this series is that the
TMP431 has an additional sensor. The register addresses for other sensors
are the same for all chips. It is therefore unnecessary to maintain two
different arrays for TMP431 and the other chips. Just use the same array
for all chips and add the TMP431 register addresses as third column.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>

The INA238 is a I2C power monitor similar to other INA2xx devices,
providing shunt voltage, bus voltage, current, power and temperature
measurements.

Signed-off-by: Nathan Rossi <nathan.rossi@digi.com>
Link: https://lore.kernel.org/r/20211102052754.817220-3-nathan@nathanrossi.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Add a property to the binding to define the selected shunt voltage gain.
This specifies the range and accuracy that applies to the shunt circuit.
This property only applies to devices that have a selectable shunt
voltage range via PGA or ADCRANGE register configuration.

Signed-off-by: Nathan Rossi <nathan.rossi@digi.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211102052754.817220-2-nathan@nathanrossi.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Document the compatible string for the Texas Instruments INA238, this
device is a variant of the existing INA2xx devices and has the same
device tree bindings (shunt resistor).

Signed-off-by: Nathan Rossi <nathan.rossi@digi.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211102052754.817220-1-nathan@nathanrossi.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

…h-AFh

Add thermal info support for AMD Family 19h Models 10h-1Fh and A0h-AFh.
Thermal info is supported via a new PCI device ID at offset 0x300h.

Signed-off-by: Babu Moger <babu.moger@amd.com>
Link: https://lore.kernel.org/r/163640829419.955062.12539219969781039915.stgit@bmoger-ubuntu
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Usage of these definitions were removed after the commit 0a4e668
("hwmon: (k10temp) Remove support for displaying voltage and current on Zen CPUs").
So, cleanup them up.

Signed-off-by: Babu Moger <babu.moger@amd.com>
Link: https://lore.kernel.org/r/163640828776.955062.15863375803675701204.stgit@bmoger-ubuntu
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Add the new PCI Device IDs to support new generation of AMD 19h family of
processors.

Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Babu Moger <babu.moger@amd.com>
Acked-by: Krzysztof Wilczyński <kw@linux.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>  # pci_ids.h
Link: https://lore.kernel.org/r/163640828133.955062.18349019796157170473.stgit@bmoger-ubuntu
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Bit 7 of the status register indicates that the chip is busy
doing a conversion. It does not indicate an alarm status.
Stop reporting it as alarm status bit.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Tests with a real chip and a closer look into the datasheet reveals
that the local and remote critical alarm status bits are swapped for
MAX6680/MAX6681.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Tests with a real chip and a closer look into the datasheet show that
MAX6654 does not support CRIT/THERM/OVERTEMP limits, so drop support
of the respective attributes for this chip.

Introduce LM90_HAVE_CRIT flag and use it to instantiate critical limit
attributes to solve the problem.

Cc: Josh Lehan <krellan@google.com>
Fixes: 229d495 ("hwmon: (lm90) Add max6654 support to lm90 driver")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

…ations

Commit b50aa49 ("hwmon: (lm90) Prevent integer underflows of
temperature calculations") addressed a number of underflow situations
when writing temperature limits. However, it missed one situation, seen
when an attempt is made to set the hysteresis value to MAX_LONG and the
critical temperature limit is negative.

Use clamp_val() when setting the hysteresis temperature to ensure that
the provided value can never overflow or underflow.

Fixes: b50aa49 ("hwmon: (lm90) Prevent integer underflows of temperature calculations")
Cc: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

The detect function had a comment "Make compiler happy" when id did not
read the second configuration register. As it turns out, the code was
checking the contents of this register for manufacturer ID 0xA1 (NXP
Semiconductor/Philips), but never actually read the register. So it
wasn't surprising that the compiler complained, and it indeed had a point.
Fix the code to read the register contents for manufacturer ID 0xa1.

At the same time, the code was reading the register for manufacturer ID
0x41 (Analog Devices), but it was not using the results. In effect it was
just checking if reading the register returned an error. That doesn't
really add much if any value, so stop doing that.

Fixes: f90be42 ("hwmon: (lm90) Refactor reading of config2 register")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>