Add a brief overview of PECI and PECI wire interface.
The documentation also contains kernel-doc for PECI subsystem internals
and PECI CPU Driver API.

Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

Add documentation for peci-cputemp driver that provides DTS thermal
readings for CPU packages and CPU cores, and peci-dimmtemp driver that
provides Temperature Sensor on DIMM readings.

Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Co-developed-by: Iwona Winiarska <iwona.winiarska@intel.com>
Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>

Add peci-dimmtemp driver for Temperature Sensor on DIMM readings that
are accessible via the processor PECI interface.

The main use case for the driver (and PECI interface) is out-of-band
management, where we're able to obtain thermal readings from an external
entity connected with PECI, e.g. BMC on server platforms.

Co-developed-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>

Add peci-cputemp driver for Digital Thermal Sensor (DTS) thermal
readings of the processor package and processor cores that are
accessible via the PECI interface.

The main use case for the driver (and PECI interface) is out-of-band
management, where we're able to obtain the DTS readings from an external
entity connected with PECI, e.g. BMC on server platforms.

Co-developed-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>

PECI is an interface that may be used by different types of devices.
Add a peci-cpu driver compatible with Intel processors. The driver is
responsible for handling auxiliary devices that can subsequently be used
by other drivers (e.g. hwmons).

Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

Add support for PECI device drivers, which unlike PECI controller
drivers are actually able to provide functionalities to userspace.

Also, extend peci_request API to allow querying more details about PECI
device (e.g. model/family), that's going to be used to find a compatible
peci_driver.

Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

PECI devices may not be discoverable at the time when PECI controller is
being added (e.g. BMC can boot up when the Host system is still in S5).
Since we currently don't have the capabilities to figure out the Host
system state inside the PECI subsystem itself, we have to rely on
userspace to do it for us.

In the future, PECI subsystem may be expanded with mechanisms that allow
us to avoid depending on userspace interaction (e.g. CPU presence could
be detected using GPIO, and the information on whether it's discoverable
could be obtained over IPMI).
Unfortunately, those methods may ultimately not be available (support
will vary from platform to platform), which means that we still need
platform independent method triggered by userspace.

Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>

Since PECI devices are discoverable, we can dynamically detect devices
that are actually available in the system.

This change complements the earlier implementation by rescanning PECI
bus to detect available devices. For this purpose, it also introduces the
minimal API for PECI requests.

Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

ASPEED AST24xx/AST25xx/AST26xx SoCs support the PECI electrical
interface (a.k.a PECI wire) that provides a communication channel with
Intel processors.
This driver allows BMC to discover devices connected to it and
communicate with them using PECI protocol.

Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Co-developed-by: Iwona Winiarska <iwona.winiarska@intel.com>
Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>

Intel processors provide access for various services designed to support
processor and DRAM thermal management, platform manageability and
processor interface tuning and diagnostics.
Those services are available via the Platform Environment Control
Interface (PECI) that provides a communication channel between the
processor and the Baseboard Management Controller (BMC) or other
platform management device.

This change introduces PECI subsystem by adding the initial core module
and API for controller drivers.

Co-developed-by: Jason M Bills <jason.m.bills@linux.intel.com>
Signed-off-by: Jason M Bills <jason.m.bills@linux.intel.com>
Co-developed-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

Add PECI controller nodes with all required information.

Co-developed-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>

Add device tree bindings for the peci-aspeed controller driver.

Co-developed-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>

Add device tree bindings for the PECI controller.

Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>

This patch adds support for Lattice's POWR1014 power manager IC.
Read access to all the ADCs on the chip are supported through
the "hwmon" "sysfs" files.

The main differences of POWR1014 compared to POWR1220 are
amount of VMON input lines: 10 on POWR1014 and 12 lines on POWR1220 and
number of output control signals: 14 on POWR1014 and 20 on POWR1220.

Signed-off-by: Michael Shych <michaelsh@nvidia.com>
Reviewed-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20220118075611.10665-4-michaelsh@nvidia.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Reduce code by using devm_hwmon_device_register_with_groups() API by
devm_hwmon_device_register_with_info() API.
The motivation is to reduce code and to allow easy support for similar
devices by the same driver.

Signed-off-by: Michael Shych <michaelsh@nvidia.com>
Reviewed-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20220118075611.10665-3-michaelsh@nvidia.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Update code alignments.

Signed-off-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20220118075611.10665-2-michaelsh@nvidia.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

There's no need to complicate examples with a platform specific macro.
It also complicates example parsing to figure out the number of
interrupt cells in examples (based on bracketing).

Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220119015514.2441231-1-robh@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Fix checkpatch issues by removing trailing whitespaces in Kconfig.

Signed-off-by: Marcello Sylvester Bauer <sylv@sylv.io>
Link: https://lore.kernel.org/r/c984b88b136a1cde16ce52c5f818886653b0f84a.1642434222.git.sylv@sylv.io
[groeck: Updated subject]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

ASUS ROG STRIX B450-F GAMING II has support of the same WMI
monitoring method as ASUS ROG STRIX B450-F GAMING.

This commit adds "ASUS ROG STRIX B450-F GAMING II" to
the list of boards that can be monitored using ASUS WMI.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
Tested-by: Aleksa Savic <savicaleksa83@gmail.com>
Link: https://lore.kernel.org/r/20220112214917.11662-1-pauk.denis@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Asus Prime X570-Pro motherboards have a T_Sensor header that can be
connected to an optional temperature probe.

Signed-off-by: Anthony DeRossi <ajderossi@gmail.com>
Link: https://lore.kernel.org/r/20220111051842.25634-1-ajderossi@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Add ABI file for informing remaining users of the
deprecation of the legacy /proc/i8k interface.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20220109214248.61759-4-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

…mm_hwmon parameters

Add documentation for fan_mult and fan_max.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20220109214248.61759-3-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

The driver should be called dell_smm_hwmon, i8k is only
an alias now.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20220109214248.61759-2-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Asus PRIME B550-PLUS motherboards have got an nct6775 chip. Its resource
range is covered by the \AMW0.SHWM OpRegion, so the chip is unusable
when using SIO. However ASUS WMI access works.

Add PRIME B550-PLUS to the list of motherboards using ASUS WMI to read
data.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20220110024712.753492-1-dmitry.baryshkov@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

ASUS Pro B550M-C/PRIME B550M-A  boards have got an nct6775 chip, but
by default there's no use of it because of resource conflict with WMI
method.

This commit adds "Pro B550M-C" and "PRIME B550M-A" to
the list of boards that can be monitored using ASUS WMI.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
Tested-by: Gregory P. Smith <greg@krypto.org>
Tested-by: Joel Wirāmu <jwp@redhat.com>
Tested-by: Jonathan Farrugia <jonfarr87@gmail.com>
Link: https://lore.kernel.org/r/20220112215013.11694-1-pauk.denis@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

If a label is defined in the device tree for this device add that
to the device specific attributes. This is useful for userspace to
be able to identify an individual device when multiple identical
chips are present in the system.

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Tested-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Link: https://lore.kernel.org/r/20220110182256.30763-3-paul@crapouillou.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Add the "label" sysfs attribute, which can contain a descriptive label
that allows to uniquely identify a device within the system.

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220110182256.30763-2-paul@crapouillou.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

These registers report CPU temperatures (and, depending on the system,
sometimes chipset temperatures) via the TSI interface on AMD systems.
They're distinct from most of the other Super-IO temperature readings
(CPUTIN, SYSTIN, etc.) in that they're not a selectable source for
monitoring and are in a different (higher resolution) format, but can
still provide useful temperature data.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Tested-by: Renze Nicolai <renze@rnplus.nl>
Link: https://lore.kernel.org/r/20220113164629.21924-1-zev@bewilderbeest.net
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Use with_info API to reduce code size and simplify the code.

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

According to the March 2013 revision of the LM82 datasheet, the latest
LM82 die revision is 0x03. This was confirmed and observed with a real
chip. Further details in this revision of the LM82 datasheet suggest that
LM82 is now just a repackaged LM83. Such versions of LM82 will be detected
as LM83. Add comment to the code explaining why this may happen.

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

There should be no message in the kernel function if the detect function
fails to identify a chip; this is perfectly normal and does not warrant
a kernel log entry. Demote message to debug.

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

…ctions

Replace TEMP_FROM_REG with direct calculation and TEMP_TO_REG
with standard functions/macros.

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

Using local caching in this driver had few benefits. It used cached values
for two seconds and then re-read all registers from the chip even if the
user only accessed a single attribute. On top of that, alarm attributes
were stale for up to four seconds (the first status register read reports
and clears an alarm, the second reports it cleared). Use regmap instead
for caching. Do not re-read non-volatile registers, and do not cache
volatile registers.

As part of this change, handle register read and write address differences
in regmap code. This is necessary to avoid problems with caching in the
regmap core, and ultimately simplifies the code.

Also, errors observed when reading from and writing to registers are no
longer ignored.

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

It has no value to name a variable 'new_client' in probe and detect
functions; it is obvious that the client is new. Use 'client' as
variable name instead.

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

There is no need to keep lm83_id at the end of the driver. Move it
forward to where it is needed to avoid a forward declaration.

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