npcm7xx_pwm_config_set() writes the channel's CMR register and then
does a read-modify-write of the CR register that holds the enable and
invert bits of all four channels of a PWM module. It is called from the
hwmon pwm write path and from npcm7xx_pwm_cz_set_cur_state(), the
set_cur_state callback of the thermal cooling devices the driver
registers for channels with "cooling-levels".
The per-module pwm_lock serializing these updates was dropped on the
assumption that the hwmon core serializes all attribute accesses. That
only covers the hwmon attributes: the cooling devices are registered
directly with the thermal core, which only holds the lock of the
cooling device being updated. So a thermal zone update or a write to a
cooling device's cur_state can run concurrently with a pwm write, or
with the cooling device of another channel of the same module, and one
CR update overwrites the other:
CPU0 (pwmN write) CPU1 (cooling dev, same module)
tmp = ioread32(CR)
tmp = ioread32(CR)
tmp |= ch1 enable
iowrite32(tmp, CR)
tmp |= ch0 enable
iowrite32(tmp, CR) /* ch1 enable bit lost */
leaving a fan stopped or running at a duty cycle that no longer matches
its enable state.
The bug was found by code inspection and has not been reproduced.
Fix by restoring a per-module mutex around the register updates; a
driver lock is used instead of hwmon_lock() because the cooling devices
are registered before the hwmon device exists.
Fixes: abfb050851 ("hwmon: (corsair-psu) Rely on subsystem locking")
Assisted-by: LLM
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The registers of the chip are banked: each access selects the bank, which
is cached in data->bank_sel, and then reads or writes the register.
bank_lock used to make the two steps atomic. It has been removed because
the hwmon core serialises the sensor callbacks, but the watchdog callbacks
use the same access functions and are not called by the hwmon core.
So a sensor can now be read while the watchdog is being pinged. If one of
them selects its bank between the two steps of the other, the second step
hits a register of the wrong bank: the watchdog is not fed, or its
commands are written to some sensor or fan control register.
Take the lock of the hwmon device in the watchdog callbacks. The watchdog
is registered after the hwmon device, and devres unregisters it first.
Fixes: 9ad270bf4d ("hwmon: (nct7904) Rely on subsystem locking")
Assisted-by: LLM
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The registers of the chip are paged: fts_read_byte() and fts_write_byte()
select the page and then access the register. access_lock used to make
the two steps atomic. It has been removed because the hwmon core
serialises the sensor callbacks, but the watchdog code uses the same two
functions and is not called by the hwmon core.
So the sensors can now be read, or an alarm be cleared, while the watchdog
is being started or stopped. If one of them selects its page between the
two steps of the other, the second step hits a register of the wrong page.
Take the lock of the hwmon device in the watchdog callbacks, and for the
accesses of fts_watchdog_init(), which runs when the hwmon device has
already been registered. These are moved to a function of their own, so
that the lock is not held while the watchdog is being registered. devres
unregisters the watchdog before the hwmon device.
Fixes: fa035d98db ("hwmon: (ftsteutates) Rely on subsystem locking")
Assisted-by: LLM
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The ACPI specification says:
"If an error occurs while obtaining the meter reading or if the value
is not available then an Integer with all bits set is returned"
This integer can also be 64-bit wide on ACPI 2.0 and later systems,
so we have to check for that too.
Compile-tested only.
Reported-by: Grant Slater <github@firefishy.com>
Closes: https://github.com/lm-sensors/lm-sensors/issues/460
Fixes: 1fefca6c57 ("hwmon: (acpi_power_meter) Fix 4.29 MW bug")
Cc: stable@vger.kernel.org
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20261006234618.10943-1-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
heater_enable_store() returns the result of i2c_master_send(), which is
the two-byte command length on success rather than the sysfs input
count. This can report more bytes than were supplied, or a partial write
for a fully processed input. For example, writing "on\n" returns two
instead of three, so a caller retrying the remaining newline gets
-EINVAL even though the heater command succeeded. Retrying the remainder
of "off\n" can also send the heater-off command twice.
Return count after a complete command transfer. Preserve negative I2C
errors and return -EIO for nonnegative incomplete transfers, so a
zero-message transfer is not reported as a successful zero-byte write.
Keep the existing boolean parsing, command selection and locking.
Fixes: 50c22cd154 ("hwmon: (sht3x) add humidity heater element control")
Cc: stable@vger.kernel.org
Signed-off-by: Baek Kyu, Kim <pocj8ur4in@gmail.com>
Link: https://patch.msgid.link/20261019154718.2328055-1-pocj8ur4in@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
mcp9982_write() updates interval_idx before writing the conversion-rate
register. If the write fails without changing the register, subsequent
update_interval reads report the requested interval instead of the
previous setting.
Update interval_idx only after regmap_write() succeeds, leaving the
previous cached interval in place on error.
Fixes: e2fe950f34 ("hwmon: add support for MCP998X")
Cc: stable@vger.kernel.org
Signed-off-by: Baek Kyu, Kim <pocj8ur4in@gmail.com>
Acked-by: Duicu Victor <victor.duicu@microchip.com>
Link: https://patch.msgid.link/20261018055750.1318723-1-pocj8ur4in@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The HID raw_event callback runs before HID core validates the received
report length. waterforce_raw_event() reads command bytes and then accesses
fixed offsets for firmware or status data without any length checks. A
truncated report can therefore cause out-of-bounds reads and update hwmon
state with unrelated data.
Require every report to contain the firmware response fields, which also
covers both command bytes. After identifying a status response, require
the byte at the highest status offset before accessing its payload.
Fixes: 42ac68e3d4 ("hwmon: Add driver for Gigabyte AORUS Waterforce AIO coolers")
Cc: stable@vger.kernel.org
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Link: https://patch.msgid.link/20260927084959.893708-1-yaojiale02@163.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Commit 0f8b916bc5 ("hwmon: (coretemp) avoid RDMSR interrupts to
isolated CPUs") prevents create_core_data() from creating temperature
data for an isolated CPU. coretemp_cpu_online(), however, still adds
that CPU to pdata->cpumask.
When an isolated SMT thread is processed before a housekeeping sibling,
the mask makes coretemp_cpu_online() believe that the core is already
represented. The housekeeping sibling then gets no temperature
attributes. Package attributes are similarly not retried when the first
CPU processed in a die is isolated.
The mask is also used to select a replacement CPU when a sensor target
goes offline. Including isolated CPUs permits the driver to retarget a
sensor to one, causing subsequent sysfs reads to send an RDMSR IPI to an
isolated CPU.
Keep isolated CPUs out of pdata->cpumask by moving the housekeeping check
to coretemp_cpu_online(). Sensor creation is then deferred to an eligible
CPU, and hotplug replacement targets remain on housekeeping CPUs.
Tested on an Intel Core i7-10510U running 6.18.50-3-cachyos-lts, with
nohz_full=1 on CPU 1 and its housekeeping SMT sibling on CPU 5. The stock
driver omitted Core 1 after module load and retained its readable sensor
after CPU 5 was offlined. The patched driver exposed Core 1, removed it
when CPU 5 went offline, and restored it when CPU 5 returned.
Fixes: 0f8b916bc5 ("hwmon: (coretemp) avoid RDMSR interrupts to isolated CPUs")
Cc: stable@vger.kernel.org
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Ximing Zhang <xzhangjr@gmail.com>
Tested-by: Asaf Nuri Bertizlioğlu <ycistak@gmail.com>
Link: https://patch.msgid.link/20261016-codex-coretemp-housekeeping-v1-1-96618c5676b2@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
__MODULE_STRING() has been an alias for __stringify() since "[PATCH]
MODULE_PARM support for older modules" [1] in 2002-12. That change also
moved it to the graveyard section at the end of linux/module.h
Replace the remaining uses of __MODULE_STRING() with __stringify() in
preparation for its removal.
Link: https://git.kernel.org/tglx/history/c/136839a1b4 [1]
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20261002-module-string-v2-1-fc7438acaf4d@suse.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for the Renesas RAA229639 and RAA229640 PMBus
voltage regulator devices.
Both devices are supported by the existing raa_dmpvr2_2rail_nontc
driver variant, so no functional changes are required beyond
adding the corresponding device IDs and OF match entries.
Signed-off-by: Colin Huang <u8813345@gmail.com>
Link: https://patch.msgid.link/20260921-add-raa229639-and-raa229640-v3-2-b104ee8a70b2@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
show_temp() reads TjMax before checking whether the cached temperature is
still fresh, but consumes it only when recomputing that temperature. On a
cache hit the value is discarded.
Discarding it is not free. On CPUs that report TjMax in
MSR_IA32_TEMPERATURE_TARGET, get_tjmax() returns the value it just read
without storing it in tdata->tjmax, so every call reads the MSR again.
That is a cross-CPU call whenever the CPU owning the sensor is not the
current one, and it is made while holding tdata->update_lock.
Read TjMax where it is used. The value cannot go stale in the meantime:
bits 23:16 of MSR_IA32_TEMPERATURE_TARGET are read-only, and the register
is package-scoped, so every CPU of the package reads the same value.
The temperature reported to userspace does not change.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Link: https://patch.msgid.link/20260924-coretemp-temp-fault-v1-2-1884f0ff97d5@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Building with W=1 reports format truncation warnings when formatting
the firmware version values for debugfs.
The SMBus helpers return the byte and word values as int, so the
compiler cannot infer that the formatted values fit into the small
temporary buffers. Cast the values to u8 and u16 before formatting
them.
This avoids the -Wformat-truncation warnings while keeping the existing
output format unchanged.
Signed-off-by: Eduard Zateev <hackerowskiy@gmail.com>
Link: https://patch.msgid.link/20260923024827.56445-1-hackerowskiy@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
On the Dell 16 DC16250, the BIOS keeps the CPU fan at its highest state
(~4700 RPM) even when the system is idle at 45 °C, and fan speed writes
through pwm1 are overridden by the BIOS within a few seconds.
The I8K_FAN_30A3_31A3 SMM code pair works on this machine through the
WMI-SMM backend: after writing 1 to pwm1_enable, the fan accepts all
three fan states (0, 128 and 255 via pwm1) and reports matching RPM,
and writing 2 hands control back to the BIOS.
Tested on BIOS 1.8.1 with kernel 7.1.5 (Pop!_OS 24.04).
Assisted-by: claude-opus-5-5
Signed-off-by: Emanuel Ávila <avilaemanueel@gmail.com>
Acked-by: Pali Rohár <pali@kernel.org>
Link: https://patch.msgid.link/20260924044829.2889204-1-avilaemanueel@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for the PWM fan controller found on the Axiado AX3000 and
AX3005 SoCs.
The controller uses a hardware tachometer block and interrupt to measure
fan speed. Fan speed is controlled through a PWM signal supplied by an
external PWM controller.
Register the controller with the hwmon subsystem and expose the standard
fan1_input and pwm1 attributes. The physical fan is represented by a fan
child node containing the PWM specifier and the optional
pulses-per-revolution property. If pulses-per-revolution is not specified,
the driver uses two pulses per revolution.
The driver was tested on AX3000 and AX3005 boards.
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
Link: https://patch.msgid.link/20260921-axiado-ax3000-pwm-fan-v3-2-3def8b6ffec9@axiado.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In preparation for making the devm_kmalloc family of allocators type
aware, we need to make sure that the returned type from the allocation
matches the type of the variable being assigned. (Before, the allocator
would always return "void *", which can be implicitly cast to any
pointer type.)
The assigned type of "info_map[type]" is "struct hp_wmi_info **", but
the converted allocation type would be "struct hp_wmi_info ***", as the
size was taken from "*info_map", which is one level of indirection too
many. Luckily both element types are pointers of the same size. Take the
size from the element type of the assignment target.
Build tested ARCH=x86_64 allmodconfig with GCC 16.2.0:
drivers/hwmon/hp-wmi-sensors.o
Assisted-by: LLM coccinelle
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
Acked-by: James Seo <james@equiv.tech>
Link: https://patch.msgid.link/20260917211338.i.682-kees@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In preparation for making the devm_kmalloc family of allocators type
aware, we need to make sure that the returned type from the allocation
matches the type of the variable being assigned. (Before, the allocator
would always return "void *", which can be implicitly cast to any
pointer type.)
The assigned type of "scmi_sensors->info[type]" is
"const struct scmi_sensor_info **", but the converted allocation type
would be "const struct scmi_sensor_info ***", as the size was taken from
"*scmi_sensors->info", which is one level of indirection too many.
Luckily both element types are pointers of the same size. Take the size
from the element type of the assignment target.
Build tested ARCH=x86_64 allmodconfig with GCC 16.2.0:
drivers/hwmon/scmi-hwmon.o
Assisted-by: LLM coccinelle
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
Link: https://patch.msgid.link/20260917211344.i.911-kees@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In preparation for making the devm_kmalloc family of allocators type
aware, we need to make sure that the returned type from the allocation
matches the type of the variable being assigned. (Before, the allocator
would always return "void *", which can be implicitly cast to any
pointer type.)
The assigned type is "const struct hwmon_channel_info **", but the
converted allocation type would be "struct hwmon_channel_info **", which
is the same type without the const qualifier. As there is no general way
to safely add const qualifiers, take the size from the assignment target
instead. No change in allocation size results.
Build tested ARCH=x86_64 allmodconfig with GCC 16.2.0:
drivers/hwmon/pwm-fan.o
Assisted-by: LLM coccinelle
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
Link: https://patch.msgid.link/20260917211417.i.173-kees@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In preparation for making the devm_kmalloc family of allocators type
aware, we need to make sure that the returned type from the allocation
matches the type of the variable being assigned. (Before, the allocator
would always return "void *", which can be implicitly cast to any
pointer type.)
The assigned type of "sensor_data->wmi.info[type]" is
"const struct asus_wmi_sensor_info **", but the converted allocation
type would be "const struct asus_wmi_sensor_info ***", as the size was
taken from "*sensor_data->wmi.info", which is one level of indirection
too many. Luckily both element types are pointers of the same size. Take
the size from the element type of the assignment target.
Build tested ARCH=x86_64 allmodconfig with GCC 16.2.0:
drivers/hwmon/asus_wmi_sensors.o
Assisted-by: LLM coccinelle
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
Link: https://patch.msgid.link/20260917211332.i.711-kees@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
tps536c7_identify() sets info->pages to 1 for a single-channel part and
then accesses page 0 (writing PMBUS_PHASE) without ensuring PAGE is
actually 0. pmbus_set_page() does not update the PAGE register when
info->pages is 1, so if boot firmware left PAGE set to another value the
PHASE writes and subsequent telemetry may target the wrong page.
Select page 0 explicitly before configuring PHASE.
Signed-off-by: Sanman Pradhan <psanman@juniper.net>
Link: https://patch.msgid.link/20260916235406.681131-3-sanman.pradhan@hpe.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use a designated initializer for the acpi_device_id fields which makes the
code more readable and consistent with how lists are initialized in the
rest of the kernel code base. Also drop explicitly setting fields to 0
where it is redundant.
Unify the list terminator to have a single space between the brackets and
no trailing comma.
Signed-off-by: Pawel Zalewski <pzalewski@thegoodpenguin.co.uk>
Link: https://patch.msgid.link/20260915-acpi-hwmon-v2-1-39d17c748eb6@thegoodpenguin.co.uk
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
TPS536C7 is a dual-channel D-CAP+ step-down controller whose channels are
distributed across a configurable number of phases (N+M, up to 12 total).
Whether channel B (PMBus page 1) exists depends on the phase configuration
register, so the page count is derived at probe time.
Factor the TPS53676 phase-map parsing into a shared helper and reuse it
for TPS536C7. Only aggregate per-channel telemetry is exposed: leave
info->phases[] unset so the PMBus core never programs the PHASE selector
on every read (and because TPS536C7 can place up to 12 phases on channel
A, exceeding PMBUS_PHASES). Report VOUT in linear format like TPS53676.
Since the core never programs PHASE, set it to 0xff on each populated
page so READ_IOUT reports the aggregate channel current, and verify it
(PHASE can be write-protected). Fail identification if aggregate
selection cannot be established, since otherwise a single phase current
could be reported as the channel total.
A configuration with no channel-A phase is rejected with -EOPNOTSUPP:
the PMBus core models pages as the contiguous range 0..pages-1 and
cannot represent a channel-A-absent topology.
On the tested TPS536C7 (device ID 54 49 53 6c 70 00, CAPABILITY 0xd0),
block reads of IC_DEVICE_ID and USER_DATA_03 return -EBADMSG with PEC
enabled, while retrying those two reads without PEC returns the expected
6- and 24-byte payloads. Standard byte/word telemetry keeps using PEC,
so only those two identification reads fall back to no-PEC.
Co-developed-by: Senthil Muniyappan <smuniyappan@juniper.net>
Co-developed-by: Vaibhav Agarwal <avaibhav@juniper.net>
Signed-off-by: Sanman Pradhan <psanman@juniper.net>
Link: https://patch.msgid.link/20260915164823.160977-4-sanman.pradhan@hpe.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
On the Dell Precision 3650 Tower, the EC ignores fan speed writes unless
automatic BIOS fan control is disabled first. The I8K_FAN_30A3_31A3 SMM
code pair works on this machine through the WMI-SMM backend: after
writing 1 to pwm1_enable, all three fans (CPU, front, top) accept the
three fan states and report matching RPM, and writing 2 hands control
back to the BIOS. I8K_FAN_34A3_35A3 was tested as well and also works;
I8K_FAN_30A3_31A3 is used since it matches recent OEM software.
Tested on BIOS 1.48.0 with kernels 7.0.0-30 and 7.0.0-31 (Ubuntu 26.04).
Signed-off-by: Patrick Pepin <patpep@me.com>
Acked-by: Pali Rohár <pali@kernel.org>
Link: https://patch.msgid.link/20260914080955.87925-1-patpep@me.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
ADPM12300 is a quarter brick DC/DC Power Module. It is a high power
non-isolated converter capable of delivering regulated 12V with
continuous power level of 3000W. Uses PMBus.
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Link: https://patch.msgid.link/20260914-dev_adpm12300-v1-1-15fc8143d457@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add Sensylink CTF2301 support to the LM63 driver. CTF2301 follows
the LM63-style temperature, tachometer, and PWM register layout,
while using a 12-bit local temperature register and requiring the
ALERT/TACH pin to be configured for tachometer input.
Register an optional thermal cooling device when the device tree
node provides #cooling-cells, allowing thermal zones to control
the fan through the existing PWM path without changing behavior
for existing LM63-family users.
Signed-off-by: Troy Mitchell <troy.mitchell@linux.dev>
Link: https://patch.msgid.link/20260914-ctl2301-v5-4-522def70acb4@linux.dev
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add temperature channel mapping for Agilex 5 and bind it to the
"intel,agilex5-svc" compatible string. Reuse the Agilex voltage channels.
Agilex 5 omits temperature channel 2 (top-left corner) because that
sensor is not present; remaining sensors keep Agilex channel numbers.
The "intel,agilex5-svc" compatible is added to the stratix10-svc match
table by a separate patch [1]. Without that change the service layer does
not bind on Agilex 5, so the socfpga-hwmon device is never created; this
patch depends on it.
Update the socfpga-hwmon documentation to list Agilex 5, the matching
compatible string, and the SDM temperature/voltage channel tables.
Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
Link: https://lore.kernel.org/all/20260907082203.2639395-4-adrian.ho.yin.ng@altera.com/ [1]
Link: https://patch.msgid.link/41bb317cbfb6f4e2711581f2ccb22071db17b19e.1789373027.git.tze.yee.ng@altera.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
It is possible for a PMBus driver to configure a phase count larger than
the PMBUS_PHASES limit and cause an out-of-bounds read.
Add a bounds check for info->phases against PMBUS_PHASES in the core API
to prevent the potential out-of-bounds read.
Cc: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Link: https://patch.msgid.link/20260912145038.2411447-1-linux@roeck-us.net
The MAX20826 IC and similar provide a high-density, flexible and scalable
dual-loop solution for high current cores for AI applications. These are
dual loop solutions multiphase voltage regulators. Between Rails A and B,
MAX20855B and MAX20908 supports up to 8 phases total configurable from
8+0 to 4+4 phases, MAX20912 supports up to 12 phases from 12+0 to 6+6,
and MAX20826 and MAX20916 supports up to 16 phases from 16+0 to 8+8.
Co-developed-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://patch.msgid.link/20260911-hwmon-max20826-support-v2-4-5e30cbd97d84@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This is in preparation for adding support to a device which needs to
use it's own read_block implementation.
The MAX20826 family is one such device. When not in PMBus page mode, each
of its two rails sits at a different I2C address, so selecting the rail
cannot be done through pmbus_set_page() and has to be handled by the
driver.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://patch.msgid.link/20260911-hwmon-max20826-support-v2-2-5e30cbd97d84@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The NCT6122D hardware monitor is the same as the NCT6126D, the only
difference if the number of UARTs: two instead of six.
Add it to the driver using the nct6126 chip kind to avoid code
duplication.
Assisted-by: opencode:z-ai/glm-5.3-flash
Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
Link: https://patch.msgid.link/20260909-bootlin-hwmon-nct6126-v1-3-4e85615fef10@bootlin.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for the hardware monitoring functionality of the NCT6126D
Super-I/O chip.
The NCT6126D hardware monitor is nearly identical to the NCT6116D: the
fan, PWM, temperature, TSI, alarm.
The differences are:
- Device IDs 0xd283 (A version) and 0xd284 (B version), which both fall
into the NCT6116D ID range (0xd280) when masked with SIO_ID_MASK.
Instead, compare the full value to distinguish from NCT6116D.
- One additional VIN: VHIF scaled at 16 mV/LSB.
- The fan count limit registers are documented for all five fans.
Also expose fan4_min.
Assisted-by: opencode:z-ai/glm-5.3-flash
Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
Link: https://patch.msgid.link/20260910-bootlin-hwmon-nct6126-v2-2-ee629ab35e49@bootlin.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The in-tree driver is solely authored by ARCTIC. Keep the existing
GPL-2.0-or-later grant and add BSD-2-Clause so the files may be used
under either license.
Signed-off-by: Aureo Serrano de Souza <aureo.serrano@arctic.de>
Link: https://patch.msgid.link/20260910050401.279868-3-aureo.serrano@arctic.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The device has no GET_REPORT and every OUT report carries all 10
channels, so the cache has to start at some value. Starting at 0
means the first sysfs write to a single channel also sends 0% on
the other nine.
The MCU factory default is 40%. Initialize pwm_duty[] to 102 (40%
on the 0-255 sysfs scale) at probe and on reset-resume. Any initial
cache can be stale if the module is reloaded without a device
reset. 40% matches the hardware after power-on or power-loss
resume, and a first single-channel write leaves the fans running
at a safe speed.
PWM is still not taken from periodic IN reports: the device is
manual-only and the host cache stays authoritative after the first
successful write.
Signed-off-by: Aureo Serrano de Souza <aureo.serrano@arctic.de>
Link: https://patch.msgid.link/20260910050401.279868-2-aureo.serrano@arctic.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use sysfs_emit() instead of sprintf() in the sysfs show functions
hih6130_temperature_show() and hih6130_humidity_show() to use the
preferred kernel interface for writing to sysfs buffers.
No functional change intended.
Note: Not runtime tested due to lack of hardware.
Signed-off-by: Massinissa Ghoul <massigh680@gmail.com>
Link: https://patch.msgid.link/20260907-hwmon-hih6130-sysfs-emit-v1-1-a1adb5245d0f@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add a hwmon driver for the temperature sensor ADC (TSADC) controller
found on Axiado AX3000 and AX3005 SoCs. The controller measures
temperature at locations within the SoC silicon die.
Each TSADC controller is registered as a separate hwmon device and
exposes one read-only temperature channel. The sensor is configured for
continuous conversion during probe.
The current TSADC hardware does not support threshold or alarm reporting.
All TSADC interrupt sources are masked during initialization, and only
the current temperature is exposed through temp1_input.
The averaged 12-bit ADC code is converted to millidegrees Celsius using
a lookup table with linear interpolation between adjacent entries. Raw
values outside the characterized lookup-table range are clamped to the
nearest supported temperature.
Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
Link: https://patch.msgid.link/20260903-axiado-ax3000-tsadc-v1-2-a8a0f3b251f5@axiado.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The LTC4286/LTC4287 driver uses rsense to scale current and power
telemetry. rsense is board-specific rather than a fixed device
characteristic, and may differ across qualified BOM variants using the
same software image.
If rsense does not match the installed board configuration, current and
power readings are mis-scaled.
Add a writable shunt_resistor sysfs attribute so userspace can update
the board calibration value after platform identification. Initialize
rsense from shunt-resistor-micro-ohms as before (or the existing default
when absent), and validate runtime updates before recalculating the
current/power scaling coefficients.
Signed-off-by: Carl Lee <carl.lee@amd.com>
Link: https://patch.msgid.link/20260907-hwmon-pmbus-ltc4286-add-runtime-shunt-resistor-control-v2-1-5f47f7e5a1bb@amd.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Fix typos in comments, reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://patch.msgid.link/20260904114249.26515-1-hemanth.selam@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add the USB product ID of the base ASUS ROG RYUJIN III 360 (0b05:1aa2,
USB product string "ROG RYUJIN III"). It uses the same status report
layout and cooler duty channel as the RYUJIN III EXTREME, EVA and
WHITE editions, so it can share rog_ryujin_iii_info.
Tested on a ROG RYUJIN III 360: coolant temperature, pump speed and
internal fan speed report plausible values that track load, and the
internal fan follows pwm2 (30% -> 870 RPM, 40% -> 1590 RPM).
Assisted-by: Claude:claude-fable-5-1
Signed-off-by: Zac Lanzon <lanzonza@gmail.com>
Link: https://patch.msgid.link/20260903004054.502171-1-lanzonza@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The ROG STRIX Z490-A GAMING and Z490-F GAMING are essentially the same
board apart from the F's onboard WiFi module, which isn't wired through
the EC, so they share the same EC sensor layout. The Z490-A exposes the
same EC sensor set as the Z490-F (chipset, CPU, motherboard, T_Sensor
and VRM temperatures plus CPU_OPT and VRM HS fans) at the same EC
registers, so reuse the Z490-F board_info for it.
Signed-off-by: Mario Nuevo <marionuevo@gmail.com>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://patch.msgid.link/20260905080346.1957380-1-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
TPS53622 and TPS53659 are dual-channel D-CAP+ step-down controllers that
use the VID VOUT format and VOUT_MODE identification like the existing
TPS53679/TPS53688, so they reuse tps53679_identify().
Shorten the Kconfig prompt to the family name and list the supported
chips in the help text instead; this also adds TPS53685, which is already
supported by the driver but was missing from the list. Update the driver
documentation, including the per-attribute lists, and fix an existing
"TPS53588" typo (should be TPS53688) in those lists.
Signed-off-by: Sanman Pradhan <psanman@juniper.net>
Link: https://patch.msgid.link/20260901211129.360792-3-sanman.pradhan@hpe.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add a DMI-gated hwmon driver for the embedded controller used by the
Minisforum UM780 XTX with board revision 1.1 and BIOS 1.06.
Expose the CPU and system fan control temperatures and tachometers. The
tachometer protocol returns one byte per OEM command, so serialize
transactions and use high-low-high sampling to reject torn values.
Allow selecting either complete OEM CPU fan profile through pwm1_enable and
changing the two validated system fan transition temperatures through
standard automatic-curve attributes. Cache coherent settings and restore
them after the firmware reloads defaults following resume.
Signed-off-by: Sebastián Peyrott <speyrott@gmail.com>
Link: https://patch.msgid.link/20260902000509.191115-1-speyrott@gmail.com
[groeck: Folded fixes for gcc-11 build failure and overflow into this patch]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Support for 16-bit addressing was removed when support for i3c
was added to the driver. Switching between 8-bit and 16-bit addressing
might confuse the system firmware, so we are forced to bail out if
16-bit addressing was configured during boot.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260901200142.495319-2-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Some Intel i2c controllers can be configured by the BIOS to reject
writes to the SPD device. This often causes problems when the register
page needs to be changed, usually during resume.
Avoid probing on affected devices by unconditionally selecting page 0
by writing the SPD5118_REG_I2C_LEGACY_MODE register during probe.
This will fail on affected controllers and thus prevent the driver
from probing.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260901200142.495319-1-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The ROG STRIX X670E-A GAMING WIFI is missing from the driver's DMI
table. Consequently, the board lookup fails with -ENODEV,
asus_ec_sensors does not load, and no asusec hwmon device or EC
temperature readings are available.
The board uses the same EC sensors, access mutex, and AMD 600-series
register layout as the ROG STRIX X670E-E GAMING WIFI. Add its DMI entry
using the existing X670E-E board information and document the board as
supported.
Before the change, there was no asusec device under /sys/class/hwmon and
there were no EC readings. After the change, the driver registered four
sensors with representative readings of 57-61 C for CPU, 68-71 C for
CPU package, 43-44 C for motherboard, and 49-52 C for VRM.
The readings correlated with nct6775 and k10temp. Repeated polling with
both hwmon drivers loaded produced no EC access, bank-switch, concurrent
access, or locking errors.
Tested on an ASUS ROG STRIX X670E-A GAMING WIFI with BIOS 2704.
Signed-off-by: Asai Neko <sugar@sne.moe>
Reviewed-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://patch.msgid.link/20260901-asus-x670e-a-hwmon-fix-v2-1-759406c2a61a@sne.moe
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
