Remove the hysteresis for low temperature limit, in hardware
the hysteresis is applied only to the maxim limit and the
critical limit temperature.
Fixes: 54392ce444 ("hwmon: (emc1403) Add support for min_hyst attributes")
Signed-off-by: Marius Cristea <marius.cristea@microchip.com>
Link: https://lore.kernel.org/r/20260813-emc1403_remove_min_hyst-v1-1-43a0d05d9f49@microchip.com
[groeck: Updated subject]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
pdata->core_data is allocated in init_temp_data() when the first core
temp_data of a package is created, but it is only released from
destroy_temp_data(), and only in the branch that handles the package
temp_data.
Package temp_data is created solely when the CPU supports
X86_FEATURE_PTS. On a CPU without it, coretemp_cpu_online() never calls
coretemp_add_core() with pkg_flag set, so pdata->pkg_data stays NULL.
coretemp_cpu_offline() then skips the removal of the package interface,
destroy_temp_data() is never called for package data, and the array is
still allocated when coretemp_device_remove() frees the platform data
that pointed at it.
Release the array in coretemp_device_remove(). destroy_temp_data() sets
pdata->core_data to NULL when it frees it, so the added kfree() is a
no-op on CPUs that do have PTS.
Tested on an Intel Core i5-1135G7. The driver was instrumented to log
every allocation and release of pdata->core_data, and the PTS check in
coretemp_cpu_online() was patched out to emulate a CPU without package
thermal support. Without this change the array was allocated and never
released, and coretemp_device_remove() still saw a non-NULL pointer.
With it the array is released and the pointer accounting balances. On an
unmodified build the release still happens via the package temp_data and
the added kfree() sees NULL, with no slab warnings over repeated module
load and unload cycles.
Fixes: 1a793caf6f ("hwmon: (coretemp) Use dynamic allocated memory for core temp_data")
Signed-off-by: Szymon Wilczek <swilczek.lx@gmail.com>
Link: https://lore.kernel.org/r/20260810192344.3733721-1-swilczek.lx@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
max6621_read() reads the CONFIG2 offset and the critical alert threshold
registers into a u32 and scales them without sign extension:
/* offset */ *val = (regval >> MAX6621_REG_TEMP_SHIFT) * 1000L;
/* crit */ *val = regval * 1000L;
Both attributes are writable and their write paths clamp to a negative
minimum and encode negative values, so a value written as negative is read
back as a large positive number. For example, writing a -10 degrees C
offset stores max6621_temp_mc2reg(-10000) = (-10 << 6) = 0xfd80; the read
then computes 0xfd80 >> 6 = 1014 -> 1014000 instead of -10000.
Cast the register value to s16 before scaling so the read preserves the
sign the write path encodes. The temperature input path already uses an s8
intermediate and is left unchanged.
Fixes: 92b64580f1 ("hwmon: (max6621) Add support for Maxim MAX6621 temperature sensor")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4
Signed-off-by: Cong Nguyen <congnt264@gmail.com>
Link: https://lore.kernel.org/r/ad0baddbd6163cf73545c8e9273258136718585c.1786334038.git.congnt264@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
MAX6621_TEMP_INPUT_MIN and MAX6621_TEMP_INPUT_MAX are used to clamp the
writable offset and critical thresholds. They are defined as -127000 and
128000.
The driver decodes the temperature through an s8 and its own comment in
max6621_read() documents an 8-bit two's complement value, whose range is
-128 to +127 degrees C. The current limits therefore reject the valid
-128 degrees C and accept +128 degrees C, which does not fit the 8-bit
range.
Correct the limits to -128000 and 127000.
Fixes: 92b64580f1 ("hwmon: (max6621) Add support for Maxim MAX6621 temperature sensor")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4
Signed-off-by: Cong Nguyen <congnt264@gmail.com>
Link: https://lore.kernel.org/r/9d3a4f1895a47794bb359a2a32fb1ccd6a15812c.1786334038.git.congnt264@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The ROG Ryujin III White Edition uses the same report layout as the
other supported Ryujin III variants. Add its USB device ID and list it
in the driver documentation.
The device was tested with the driver on the author's hardware.
Link: https://github.com/aleksamagicka/asus_rog_ryujin-hwmon/pull/10
Signed-off-by: Will Smith <github@notthatwillsmith.com>
Assisted-by: Codex:gpt-5.6-sol sparse
Signed-off-by: Arie Miller <renari@arimil.com>
Reviewed-by: Aleksa Savic <savicaleksa83@gmail.com>
Link: https://lore.kernel.org/r/20260812103532.395049-4-renari@arimil.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The ROG Ryujin III uses different report offsets and a different
cooler-duty channel from the Ryujin II. It also lacks the separate
external fan controller supplied with the older model.
Add model data and USB IDs for the Extreme and EVA Edition variants.
Skip controller commands and hide the unavailable controller hwmon
channels for these devices. Update the driver documentation, Kconfig
text, and module description accordingly.
Link: https://github.com/aleksamagicka/asus_rog_ryujin-hwmon/pull/9
Assisted-by: Codex:gpt-5.6-sol sparse
Signed-off-by: Arie Miller <renari@arimil.com>
Reviewed-by: Aleksa Savic <savicaleksa83@gmail.com>
Link: https://lore.kernel.org/r/20260812103532.395049-3-renari@arimil.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Move model-specific report offsets and capabilities into a device
information structure. This prepares the driver for coolers which use
a different report layout or do not include the external fan
controller, while preserving the existing Ryujin II 360 behavior.
Handles an issue reported by Sashiko where an id could
be missing driver_data.
Link: https://lore.kernel.org/r/5a817284-a9f4-48b2-9f0f-802c5dc6963c@roeck-us.net
Assisted-by: Codex:gpt-5.6-sol sparse
Signed-off-by: Arie Miller <renari@arimil.com>
Reviewed-by: Aleksa Savic <savicaleksa83@gmail.com>
Link: https://lore.kernel.org/r/20260812103532.395049-2-renari@arimil.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for per-CCD temperature monitoring on Zen 5 Turin (EPYC 9005)
CPUs, as they fall into a separate model range with a different offset
and a higher maximum CCD count than their desktop counterparts. As such,
this patch also updates the driver to support CPUs with up to 16 CCDs.
Tested and working on an EPYC 9555P.
Signed-off-by: Gabriel Ford <gabriel@gford.dev>
Link: https://lore.kernel.org/r/20260813170232.3841-1-gabriel@gford.dev
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The TMP113 temperature sensor part is register compatible with TMP102,
add non-DT I2C device ID. Unlike TMP102 and TMP110, the TMP113 does
have additional unique ID registers, those are currently unused.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://lore.kernel.org/r/20260813090456.70816-2-marex@nabladev.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
NCT5585D uses the same chip ID (0xd428) as NCT6798D and is fully
compatible with it. Tested on an ASUS PRIME H610M-D motherboard.
Signed-off-by: Jiazhi Huang <huangjia2hi@163.com>
Link: https://lore.kernel.org/r/20260811093744.12199-3-huangjia2hi@163.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The NCT6797D and NCT6798D chips are already supported by the driver
but were missing from the documentation.
Signed-off-by: Jiazhi Huang <huangjia2hi@163.com>
Link: https://lore.kernel.org/r/20260811093744.12199-2-huangjia2hi@163.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for VDD power supply for this sensor. It is required on some
devices for the sensor to start up and work properly.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://lore.kernel.org/r/20260731113007.145322-4-clamor95@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add OF match compatible table to be able to use this driver with Device
Trees.
Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://lore.kernel.org/r/20260731113007.145322-3-clamor95@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The ROG STRIX Z390-E GAMING and Z390-F GAMING are essentially the
same board apart from the E's onboard WiFi, so they share the same
EC sensor layout.
Signed-off-by: Rodrigo Araujo <araujo.rm@gmail.com>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20260809212705.1501382-1-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Switch to the __DEVICE_ATTR() macro which can handle callbacks taking
both const and non-const attribute structure arguments.
Allow the step-wise migration of the drivers.
Also use container_of_const() over container_of() to avoid casting away
the constness accidentally.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20260806-sysfs-const-attr-hwmon-v2-3-22fee8b85509@weissschuh.net
[groeck: Squashed 'hwmon: (core) Constify PEC device attribute']
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add information about the HX1500i 2025 series and fix the missing
HX1500i in Kbuild.
Signed-off-by: Wilken Gottwalt <wilken.gottwalt@posteo.net>
Link: https://lore.kernel.org/r/anVuBd8Bb7T66OUO@monster.localdomain
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add DMI quirk entries and map correct ACPI paths and configurations for
additional Lenovo laptop models including the LOQ 15IAX9,
XiaoXin Pro 13ARE 2020, IdeaPad 3 15ALC6, Legion Pro 7 16AFR10H,
Yoga Pro 7 14IAH10, and Yoga 7 16ARP8.
Reorder the DMI quirk table to evaluate specific model matches before
generic family fallbacks, preventing DMI shadowing.
Signed-off-by: Sergio Melas <sergiomelas@gmail.com>
Link: https://lore.kernel.org/r/20260806131103.19104-1-sergiomelas@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The ADT7470 features four PWM outputs designed to control fans.
Previously, these were only accessible through the legacy hwmon
sysfs interface.
Expose the ADT7470 fan control lines through the generic PWM framework.
This allows generic PWM consumers described in Device Tree, such as
"pwm-fan", to use the device through the "#pwm-cells" property. This is
particularly necessary for boards where the ADT7470 external temperature
sensors are not populated and the chip is used strictly as a fan
controller (e.g., Edgecore ECS-2100-52T switches). In such setups,
delegating control to the generic PWM subsystem allows the kernel's
thermal framework to manage the fans based on unrelated temperature
zones, such as internal SoC sensors.
When a PWM consumer applies a new PWM state, the driver automatically
switches the corresponding PWM channel to manual mode so that the
requested duty cycle takes effect. The duty cycle specified by the PWM
framework is internally converted to the 0-255 scale expected by the
hardware registers.
To prevent conflicting access, the hwmon PWM sysfs attributes are hidden
when the device is registered with PWM framework support (i.e. when
"#pwm-cells" is present in DT and CONFIG_PWM is reachable).
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://lore.kernel.org/r/20260805-adt7470_thermalzone-v6-3-5605a5f95467@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The Analog Devices ADT7470 is a multichannel temperature sensor and
PWM fan controller. It supports monitoring up to 10 external
temperature sensors and controlling up to 4 fans.
Add the device tree binding documentation for it. This includes
support for the thermal framework by defining the "#thermal-sensor-cells"
property, and models the fan control lines as PWM channels by
defining the "#pwm-cells" property.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://lore.kernel.org/r/20260805-adt7470_thermalzone-v6-1-5605a5f95467@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver uses i2c_smbus_read_i2c_block_data() for PMBus block commands.
Use pmbus_read_smbus_i2c_block_data() instead to enable the driver to work
with I2C controllers which do not support i2c_smbus_read_i2c_block_data().
Drop the functionality check to get an explicit error message if the
required SMBus commands are not supported.
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver tries to use both pmbus_read_smbus_i2c_block_data() and
i2c_smbus_read_i2c_block_data() for PMBus block commands.
Use pmbus_read_smbus_i2c_block_data() instead to simplify the code.
Drop the functionality check to simplify the code and to trigger a return
with -EOPNOTSUPP if SMBus block commands are not supported.
Cc: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Cc: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver uses a mix of pmbus_read_smbus_i2c_block_data() and
i2c_smbus_read_i2c_block_data() for PMBus block commands.
Use pmbus_read_smbus_i2c_block_data() instead to enable the driver to work
I2C controllers which do not support both block commands.
Drop the functionality check to simplify the code and to trigger a return
with -EOPNOTSUPP if SMBus block commands are not supported.
As part of this patch, rework detection of LT7170 and LT7171. The return
length of pmbus_read_smbus_i2c_block_data() may be less than the requested
number of bytes, meaning the return length needs to be checked. Also,
checking for "LT7170-1" after checking for "LT7170" and checking for
"LT7171-1" after checking for "LT7171" is pointless since the first check
will already produce a match, so drop the second part of the check.
Cc: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Cc: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver uses i2c_smbus_read_block_data() for PMBus block commands.
Use pmbus_read_smbus_i2c_block_data() instead to enable the driver to work
with I2C controllers which do not support i2c_smbus_read_block_data().
Drop the functionality check to get an explicit error message if the
required SMBus commands are not supported.
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
PMBus drivers need support for reading SMBus block data. Unfortunately,
not all i2C controllers support this command.
Implement pmbus_read_smbus_i2c_block_data() which first tries to use
i2c_smbus_read_block_data(). If not supported, try to emulate it by calling
i2c_smbus_read_i2c_block_data(). Export the new function for use in PMBus
drivers.
Cc: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Cc: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The write cases of debugfs entries are provisioning and bench
helpers. By designs the MPQ8646 powers the CPU core rail,
so a wrong write can brown out the board or persist a bad
setpoint into finite-cycle NVM.
Said differently: some wrong register writes can and likely
will physically damage or destroy the chip and/or the board.
To be safe, it is disabled by default behind a
CONFIG_SENSORS_MPQ8646_DEBUG_UNSAFE and we print an explicit warning
banner at probe time when they are built in.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Link: https://lore.kernel.org/r/20260730-mpq8646_v0-v7-4-e7c7ad768d5d@free.fr
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add a new driver for the MPS MPQ8646 that is a PMBus device.
Beyond basic PMBus telemetry, the driver adds:
- alarm acknowledge via inX_reset_history.
- STATUS_WORD MPS-extended bit decode and the NVM-backed
PROTECTION_LAST post-mortem, exposed as a read-only debugfs
decoder.
- In-driver alarm-poll fallback work item (thanks lm90) for
boards without SMBALERT
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Link: https://lore.kernel.org/r/20260730-mpq8646_v0-v7-3-e7c7ad768d5d@free.fr
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The MPS MPQ8646 PMBus step-down converter uses the same
mps,vout-fb-divider-ratio-permille property with the same constraints
(maximum 2047, default 706) as the mps,mpq8785, so add its compatible
to the existing schema.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260730-mpq8646_v0-v7-2-e7c7ad768d5d@free.fr
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Factor of pmbus_fault_handler() into an exported helper so
drivers can notify sequence from a polling work item on boards
for which the chip's SMBALERT# pin is not wired to the
CPU. The interrupt handler becomes a thin wrapper.
Like the SMBALERT# path, the helper notifies and then clears the
latched faults unconditionally, so a polling caller inherits exactly
the interrupt semantics.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Link: https://lore.kernel.org/r/20260730-mpq8646_v0-v7-1-e7c7ad768d5d@free.fr
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Replace OF property handling with fwnode in the probe function to read
the channels properties, improving the driver compatibility since this
method is not limited to Device Tree only.
Add also the needed headers for explicit include and clean up related
function naming.
Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
Link: https://lore.kernel.org/r/20260730091409.10544-1-flaviu.nistor@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Commit 554b3529fe ("thermal/drivers/core: Remove the module Kconfig's
option") [1] obviated some of the "Optional dependencies" (as described in
"Documentation/kbuild/kconfig-language.rst") in "drivers/hwmon/Kconfig".
Namely, said commit restricted the valid/possible subset of the full
Cartesian product "CONFIG_THERMAL x CONFIG_THERMAL_OF" to
{ (n, n), (y, n), (y, y) }
through "drivers/thermal/Kconfig". Numerically (using tristate values),
this set can be expressed as:
{ (0, 0), (2, 0), (2, 2) }
Over this set, the "drivers/hwmon/Kconfig" tristate expression
THERMAL || !THERMAL_OF
or equivalently,
max(THERMAL, 2-THERMAL_OF)
invariably evaluates to "y" (2).
Similarly, with THERMAL having been restricted to
{ n, y }
or numerically,
{ 0, 2 }
the "drivers/hwmon/Kconfig" tristate expression
THERMAL || THERMAL=n
or equivalently,
max(THERMAL, THERMAL=0)
invariably evaluates to "y" (2). (Note that "THERMAL=0" returns either "y"
(2) or "n" (0).)
Commit f37353320e ("hwmon/drivers/core: Simplify complex dependency")
[2], which is the final commit of the series that [1] is the beginning of,
cleaned up the hwmon C source code in fact; however, it missed the
now-collapsed dependencies in Kconfig. At the time of [2], six of today's
such dependencies were present in Kconfig. Since then, two more have been
added (such that they persist, anyway): one by commit 4f8d374b77
("hwmon: (max6650) add thermal cooling device capability"), which was
independent of the above-noted series, and another by commit 9855caf5d4
("hwmon: add driver for the hwmon parts of qnap-mcu devices"), which was a
descendant of the series.
Remove these always-"y" dependencies.
Cc: Andrew Jeffery <andrew@codeconstruct.com.au>
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Joel Stanley <joel@jms.id.au>
Cc: Sudeep Holla <sudeep.holla@kernel.org>
Cc: arm-scmi@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-aspeed@lists.ozlabs.org
Cc: linux-hwmon@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Laszlo Ersek <laszlo.ersek@arm.com>
Link: https://lore.kernel.org/r/20260729215436.2103380-1-laszlo.ersek@arm.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for MAX20830C and MAX20840 step-down DC-DC switching
regulator with PMBus interface. MAX20830C is a different packaging
for MAX20830, and MAX20840C supports 40A regulation compared to
MAX20830 that is only 30A.
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Link: https://lore.kernel.org/r/20260730-dev-max20830c-v5-4-a7553f84ee74@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add compatible strings for variants of MAX20830 which are MAX20830C
and MAX20840C. These devices have the same register functionality with
MAX20830 but with a longer IC_DEVICE_ID.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Link: https://lore.kernel.org/r/20260730-dev-max20830c-v5-3-a7553f84ee74@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Implement support for external voltage divider scaling using the
adi,vout-rfb1-ohms and adi,vout-rfb2-ohms device tree properties.
When the desired output voltage exceeds VREF, a resistor divider
(RFB1 and RFB2) is used to scale down the feedback voltage. The
driver reads these resistor values from device tree and applies
the scaling formula: VOUT_actual = VOUT_measured × (1 + RFB1/RFB2)
The properties are optional. If not specified, the driver assumes
no voltage divider is present and reports the raw VOUT reading.
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Link: https://lore.kernel.org/r/20260730-dev-max20830c-v5-2-a7553f84ee74@analog.com
[groeck: Fixed minor conflicts]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add adi,vout-rfb1-ohms and adi,vout-rfb2-ohms properties to support
external voltage divider configuration for VOUT sensing. When the
desired output voltage is higher than VREF, a resistor divider (RFB1
and RFB2) is required to reach the intended value.
The properties use a dependency constraint to ensure both resistors
are specified together, or neither. This prevents misconfiguration
where only one resistor value is provided.
This patch also adds missing entries in the examples.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Link: https://lore.kernel.org/r/20260730-dev-max20830c-v5-1-a7553f84ee74@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Some PMBus chips do not support the PMBUS_REVISION command. Knowing
the PMBUs revision supported by a chip is relevant for PMBUs core
functionality, so add support for letting chip drivers report the PMBUs
revision.
Use the new capability to report the PMBus revision supported by MAX20830.
While at it, add definitions for PMBUs revisons 1.3.1 and 1.4.
Cc: Nuno Sá <nuno.sa@analog.com>
Cc: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The Kraken 2024 Elite (USB ID 1e71:3012) is protocol-compatible with the
existing Kraken 2023 devices and works with the current Z53 code paths.
Add its USB product ID and map it to the KRAKEN2023 kind.
Tested on hardware: liquid temperature and pump/fan speeds read
correctly (cross-checked against liquidctl), and PWM control of both the
pump and fan channels works as expected.
Signed-off-by: Sean Lyon <sean@seanlyon.dev>
Link: https://lore.kernel.org/r/20260728031127.26553-1-sean@seanlyon.dev
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add a PMBus driver for the Analog Devices MAX16545 and MAX16550, and the
Volterra VT7505 controllers. The driver reports input/output voltage,
input/output current, input power and temperature over PMBus. All values
use the direct data format. Peak input voltage, output voltage, output
current, input power and temperature readings are exposed and can be
reset.
The reported current and power depend on the external current-report
resistor connected to the ILOAD pin, which can be provided through the
"adi,rload-ohms" device tree property.
On the MAX16550 and VT7505, the severe-OCP deglitch time can optionally
be configured with the "adi,ocp-severe-filter-us" device tree property.
When omitted, the existing hardware setting is left unchanged.
Co-developed-by: Dhruva Devineni <ddevineni@juniper.net>
Co-developed-by: Debjit Ghosh <dghosh@juniper.net>
Co-developed-by: JawaharBalaji Thirumalaisamy <jawaharb@juniper.net>
Co-developed-by: Avadhut Naik <avadhutn@juniper.net>
Co-developed-by: Santhanakrishnan Balraj <sbalraj@juniper.net>
Co-developed-by: Brian Mak <makb@juniper.net>
Signed-off-by: Georgi Vlaev <gvlaev@juniper.net>
Signed-off-by: Sanman Pradhan <psanman@juniper.net>
Link: https://lore.kernel.org/r/20260725211945.288415-3-sanman.pradhan@hpe.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add device tree binding documentation for the Analog Devices MAX16545 and
MAX16550, and the Volterra VT7505 PMBus controllers.
Signed-off-by: Sanman Pradhan <psanman@juniper.net>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260725211945.288415-2-sanman.pradhan@hpe.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The Kandou KB9002 is an 8-lane PCIe 5.0 retimer that exposes an SMBus
target with mandatory PEC. Add a hwmon driver reporting the firmware
aggregated maximum die temperature as temp1_input, with the firmware
version and boot status under debugfs.
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
Link: https://lore.kernel.org/r/20260724-kb9002-upstream-v5-3-9523c3ffe83a@amd.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The Kandou KB9002 is an 8-lane PCIe 5.0 retimer exposing an SMBus target
that reports an aggregated die temperature. It needs no device-specific
device tree properties beyond its address, so add it to trivial-devices.
Signed-off-by: Andy Chung <Andy.Chung@amd.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260724-kb9002-upstream-v5-2-9523c3ffe83a@amd.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
