Add support for the temperatur sensor and the fan controller on the
Microchip LAN966x SoC. Apparently, an Analog Bits PVT sensor is used
which can measure temperature and process voltages. But only a forumlae
for the temperature sensor is known. Additionally, the SoC support a fan
tacho input as well as a PWM signal to control the fan.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20220401214032.3738095-5-michael@walle.cc
[groeck: Added missing reference in Documentation/hwmon/index.rst]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Add a binding for the temperature sensor and the fan controller on the
Microchip LAN966x family.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20220401214032.3738095-4-michael@walle.ccSigned-off-by: Guenter Roeck <linux@roeck-us.net>

The polynomial calculation function was moved into lib/ to be able to
reuse it. Move over to this one.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20220401214032.3738095-3-michael@walle.ccSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Some temperature and voltage sensors use a polynomial to convert between
raw data points and actual temperature or voltage. The polynomial is
usually the result of a curve fitting of the diode characteristic.

The BT1 PVT hwmon driver already uses such a polynonmial calculation
which is rather generic. Move it to lib/ so other drivers can reuse it.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20220401214032.3738095-2-michael@walle.ccSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Add support for devices XDPE152C4, XDPE12584.
Signed-off-by: Greg Schwendimann <Greg.Schwendimann@infineon.com>
Link: https://lore.kernel.org/r/5e6d50e9b28140158f339b0de343eea4@infineon.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Several of the manuals for devices supported by this driver describes
the need for a minimum wait time before the chip is ready to receive
next command.

This wait time is already implemented in the driver as a ltc_wait_ready
function with a driver defined wait time of 100 ms, and is considered
for specific devices before reading/writing data on the pmbus.

Since this driver uses the default pmbus_regulator_ops for the enable/
disable/is_enabled functions we should add a driver specific callback
for write_byte_data to prevent bypassing the wait time recommendations
for the following devices: ltc3880/ltc3882/ltc3883/ltc3884/ltc3886/
ltc3887/ltc3889/ltm4664/ltm4675/ltm4676/ltm4677/ltm4678/ltm4680/ltm4686/
ltm4700/ltc7880.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20220428144039.2464667-4-marten.lindahl@axis.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Some of the pmbus core functions uses pmbus_read_byte_data, which does
not support driver callbacks for chip specific write operations. This
could potentially influence some specific regulator chips that for
example need a time delay before each data access.

Lets use _pmbus_read_byte_data with callback check.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20220428144039.2464667-3-marten.lindahl@axis.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Some of the pmbus core functions uses pmbus_write_byte_data, which does
not support driver callbacks for chip specific write operations. This
could potentially influence some specific regulator chips that for
example need a time delay before each data access.

Lets add support for driver callback with _pmbus_write_byte_data.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20220428144039.2464667-2-marten.lindahl@axis.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Add PRIME X470-PRO to the list of supported boards.
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20220427180237.1475954-1-eugene.shalygin@gmail.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

This board is supposed to be handled by the asus-wmi-sensors driver,
but due to a buggy WMI implementation the driver and the official ASUS
software make the BIOS hang together with fan controls [1, 2].

This driver complements values provided by the SIO chip and does not
freeze the BIOS, as tested by a user [2].

[1] https://github.com/electrified/asus-wmi-sensors/blob/master/README.md
[2] https://github.com/zeule/asus-ec-sensors/issues/12Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20220427143001.1443605-5-eugene.shalygin@gmail.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

DSDT code for AMD 400-series chipset shows that sensor addresses differ
for this generation from those for the AMD 500-series boards.
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20220427143001.1443605-4-eugene.shalygin@gmail.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

For some board models ASUS uses the global ACPI lock to guard access to
the hardware, so do we.
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20220427143001.1443605-3-eugene.shalygin@gmail.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

We need to keep some more information about the current board than just
the sensors set, and with more boards to add the dmi id array grows
quickly. Our probe code is always the same so let's switch to a custom
test code and a custom board info array. That allows us to omit board
vendor string (ASUS uses two strings that differ in case) in the board
info and use case-insensitive comparison, and also do not duplicate
sensor definitions for such board variants as " (WI-FI)" when sensors
are identical to the base variant.

Also saves a quarter of the module size by replacing big dmi_system_id
structs with smaller ones.
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20220427143001.1443605-2-eugene.shalygin@gmail.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Instead of registering the hwmon device at probe time, use the
existing "occ_active" sysfs file to control when the driver polls
the OCC for sensor data and registers with hwmon. The reason for
this change is that the SBE, which is the device by which the
driver communicates with the OCC, cannot handle communications
during certain system state transitions, resulting in
unrecoverable system errors.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/20220427140443.11428-1-eajames@linux.ibm.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

This splits the nct6775 driver into an interface-independent core and
a separate platform driver that wraps inb/outb port I/O (or asuswmi
methods) around that core.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Tested-by: Renze Nicolai <renze@rnplus.nl>
Link: https://lore.kernel.org/r/20220427010154.29749-7-zev@bewilderbeest.netTested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Checkpatch has been warning about these for a while; the octal
versions are both more comprehensible and more concise.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Link: https://lore.kernel.org/r/20220427010154.29749-6-zev@bewilderbeest.netTested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

When enabled, all write bits are removed from the modes of all sysfs
attribute files.  This provides a bit of infrastructure for the
upcoming i2c version of this driver, which should generally avoid
writes to device registers so as not to interfere with simultaneous
use of the device via the LPC interface.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20220427010154.29749-5-zev@bewilderbeest.netTested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

We now track the number of attribute groups in nct6775_data, as a
measure to simplify handling differences in the set of enabled
attribute groups between nct6775 drivers (platform & i2c).  As a side
effect, we also reduce the amount of IS_ERR()/PTR_ERR() boilerplate a
bit.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20220427010154.29749-4-zev@bewilderbeest.netTested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

This replaces the nct6775_data->{read,write}_value function pointers
with a regmap.

The major difference is that the regmap access functions may fail, and
hence require checking at each call site.  While the existing WMI
register-access code had potential failure paths, they were masked by
the fact that the read_value() function returned the register value
directly, and hence squashed errors undetectably by simply returning
zero, and while the write_value() functions were capable of reporting
errors, all callers ignored them.

This improves the robustness of the existing code, and also prepares
the driver for an i2c version to be added soon, for which register
accesses are much more likely to actually fail.

The conversion of the register-access call sites is largely mechanical
(reading a register now returns the value via an out-param pointer,
and returned errors must be checked for and propagated to callers),
though the nct6775_write_fan_div() function is refactored slightly to
avoid duplicating nearly identical (and now lengthier) code in each
switch case.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20220427010154.29749-3-zev@bewilderbeest.netTested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

If a particular SMM call takes a very long time to execute,
the user might experience audio problems. Print a warning
if a particular SMM call took over 0.250 seconds to execute,
so the user can check whether or not possible audio problems
are caused by this driver.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20220426213154.724708-4-W_Armin@gmx.deSigned-off-by: Guenter Roeck <linux@roeck-us.net>

The default values for i8k_fan_mult and i8k_fan_max
should be assigend only if the values specified as
module params or in DMI are invalid/missing.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20220426213154.724708-3-W_Armin@gmx.deSigned-off-by: Guenter Roeck <linux@roeck-us.net>

When the driver tries to detect the fan multiplier during
module initialisation, it issues one SMM call for each fan.
Those SMM calls are however redundant and also try to query
fans which may not be present.
Fix that by detecting the fan multiplier during hwmon
initialisation when no extra SMM calls are needed.
Also dont assume the last nominal speed entry to be the
biggest and instead check all entries.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20220426213154.724708-2-W_Armin@gmx.deSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Atmel (now Microchip) AT30TS74 is an LM75 compatible sensor. Add it.
Signed-off-by: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/9494dfbc-f506-3e94-501d-6760c487c93d@axentia.seSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Document the Atmel (now Microchip) AT30TS74 which is an LM75 based
temperature sensor.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
Link: https://lore.kernel.org/r/9c01b1b5-871a-2b34-9f98-766d043e0759@axentia.seSigned-off-by: Guenter Roeck <linux@roeck-us.net>

When ti,n-factor, ti,beta-compentation are not defined in devicetree,
of_property_read_u32|s32 returns -EINVAL. In this case,
tmp401_init_client should return 0 instead of simply pass ret to its
caller.
Signed-off-by: Camel Guo <camel.guo@axis.com>
Link: https://lore.kernel.org/r/20220425100019.562781-1-camel.guo@axis.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Adding another MAX16602 chip support to MAX16601 driver
Tested with MAX16602 works as expected.
Signed-off-by: Atif Ofluoglu <atif.ofluoglu@maximintegrated.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Extend aquacomputer_d5next driver to expose hardware
temperature sensors of the Aquacomputer Farbwerk RGB controller, which
communicates through a proprietary USB HID protocol.

Four temperature sensors are available. Additionally, serial number and
firmware version are exposed through debugfs.

Also, add Jack Doan to MAINTAINERS for this driver.
Signed-off-by: Jack Doan <me@jackdoan.com>
Signed-off-by: Aleksa Savic <savicaleksa83@gmail.com>
Link: https://lore.kernel.org/r/YmTcrq8Gzel0zYYD@jackdeskSigned-off-by: Guenter Roeck <linux@roeck-us.net>

When adding the Inspiron 3505 to the fan type blacklist,
the Documentation was not updated to mention the firmware
bug on this machine.
Fix that.

Fixes: 6ba463ed (hwmon: (dell-smm) Add Inspiron 3505 to fan type blacklist)
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20220424154824.9396-1-W_Armin@gmx.deSigned-off-by: Guenter Roeck <linux@roeck-us.net>

S-34TS04A is a JC42 compatible 2-wire serial EEPROM with temperature sensor
from Seiko Instruments/ABLIC.
Signed-off-by: Oleksandr Shamray <oleksandrs@nvidia.com>
Reviewed-by: Vadim Pasternak <vadimp@nvidia.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

tmp401 driver supports TMP401, TMP411 and TMP43X temperature sensors.
According to their datasheet:
- all of them support extended temperature range feature;
- TMP411 and TPM43X support n-factor correction feature;
- TMP43X support beta compensation feature.

In order to support setting them during bootup, this commit reads
ti,extended-range-enable, ti,n-factor and ti,beta-compensation and set
the corresponding registers during probing.
Signed-off-by: Camel Guo <camel.guo@axis.com>
Link: https://lore.kernel.org/r/20220414075824.2634839-3-camel.guo@axis.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Document the TMP401, TMP411 and TMP43x device devicetree bindings
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Camel Guo <camel.guo@axis.com>
Link: https://lore.kernel.org/r/20220414075824.2634839-2-camel.guo@axis.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Until now, only the temperature sensors where exported thru
the thermal subsystem. Export the fans as "dell-smm-fan[1-3]" too
to make them available as cooling devices.
Also update Documentation and fix a minor issue with the alphabetic
ordering of the includes.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20220410163935.7840-1-W_Armin@gmx.deSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Basing on information and testing provided by users [1] add support for
another board, ASUS ProArt X570 Creator WiFi.

[1] https://github.com/zeule/asus-ec-sensors/issues/17Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20220422111737.1352610-1-eugene.shalygin@gmail.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Instead of open-coding the bad characters replacement in the hwmon name,
use the new devm_hwmon_sanitize_name().
Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Xu Yilun <yilun.xu@intel.com>
Reviewed-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20220405092452.4033674-3-michael@walle.ccSigned-off-by: Guenter Roeck <linux@roeck-us.net>

More and more drivers will check for bad characters in the hwmon name
and all are using the same code snippet. Consolidate that code by adding
a new hwmon_sanitize_name() function.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20220405092452.4033674-2-michael@walle.ccSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Extend aquacomputer_d5next driver to expose hardware temperature sensors
and fans of the Aquacomputer Octo fan controller, which communicates
through a proprietary USB HID protocol.

Four temperature sensors and eight PWM controllable fans are available.
Additionally, serial number, firmware version and power-on count are
exposed through debugfs.

This driver has been tested on x86_64.
Signed-off-by: Aleksa Savic <savicaleksa83@gmail.com>
Link: https://lore.kernel.org/r/20220404134212.9690-1-savicaleksa83@gmail.com
[groeck: Add missing "select CRC16"]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Use devm_delayed_work_autocancel() instead of hand writing it. This is
less verbose and saves a few lines of code.

devm_delayed_work_autocancel() uses devm_add_action() instead of
devm_add_action_or_reset(). This is fine, because if the underlying memory
allocation fails, no work has been scheduled yet. So there is nothing to
undo.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Iwona Winiarska <iwona.winiarska@intel.com>
Link: https://lore.kernel.org/r/fd277a708ede3882d7df6831f02d2e3c0cb813b8.1644781718.git.christophe.jaillet@wanadoo.frSigned-off-by: Guenter Roeck <linux@roeck-us.net>

WS X570-ACE has a T_Sensor header on board according to manual[1].

I'm using a 10kΩ B=3435K thermsistor attached to the header of WS X570-ACE.
EC byte at 0x3d matches readings from BIOS sensor page and environment temperature.

[1]https://www.asus.com/Motherboards-Components/Motherboards/All-series/Pro-WS-X570-ACE/HelpDesk_Manual/Signed-off-by: Wei Shuyu <wsy@dogben.com>
Link: https://lore.kernel.org/r/E1nY43Q-000rAm-9a@dogben.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>

Add a thermal zone interface to the devices added
under jc42 driver. This way, thermal zones described
in device tree can make use of the of nodes of these
devices.

Cc: Guenter Roeck <linux@roeck-us.net> (maintainer:JC42.4 TEMPERATURE SENSOR DRIVER)
Cc: Jean Delvare <jdelvare@suse.com> (maintainer:HARDWARE MONITORING)
Cc: linux-hwmon@vger.kernel.org (open list:JC42.4 TEMPERATURE SENSOR DRIVER)
Cc: linux-kernel@vger.kernel.org (open list)
Signed-off-by: Eduardo Valentin <eduval@amazon.com>
Signed-off-by: Eduardo Valentin <evalenti@kernel.org>
Link: https://lore.kernel.org/r/20220318233011.13980-1-eduval@amazon.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>