Vadim Pasternak [Mon, 13 Jan 2025 08:48:59 +0000 (10:48 +0200)]
hwmon: (mlxreg-fan) Add support for new flavour of capability register
FAN platform data is common across the various systems, while fan
driver should be able to apply only the fan instances relevant
to specific system.
For example, platform data might contain descriptions for fan1,
fan2, ..., fan{n}, while some systems equipped with all 'n' fans,
others with less.
Also, on some systems fan drawer can be equipped with several
tachometers and on others only with one.
For detection of the real number of equipped drawers and tachometers
special capability registers are used.
These registers used to indicate presence of drawers and tachometers
through the bitmap.
For some new big modular systems this register will provide presence
data by counter.
Use slot parameter to distinct whether capability register contains
bitmask or counter.
Vadim Pasternak [Mon, 13 Jan 2025 08:48:58 +0000 (10:48 +0200)]
hwmon: (mlxreg-fan) Separate methods of fan setting coming from different subsystems
Distinct between fan speed setting request coming for hwmon and
thermal subsystems.
There are fields 'last_hwmon_state' and 'last_thermal_state' in the
structure 'mlxreg_fan_pwm', which respectively store the cooling state
set by the 'hwmon' and 'thermal' subsystem.
The purpose is to make arbitration of fan speed setting. For example, if
fan speed required to be not lower than some limit, such setting is to
be performed through 'hwmon' subsystem, thus 'thermal' subsystem will
not set fan below this limit.
Currently, the 'last_thermal_state' is also be updated by 'hwmon' causing
cooling state to never be set to a lower value.
Eliminate update of 'last_thermal_state', when request is coming from
'hwmon' subsystem.
Fixes: da74944d3a46 ("hwmon: (mlxreg-fan) Use pwm attribute for setting fan speed low limit") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20250113084859.27064-2-vadimp@nvidia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Sung-Chi Li [Thu, 11 Sep 2025 06:56:36 +0000 (06:56 +0000)]
hwmon: (cros_ec) register fans into thermal framework cooling devices
Register fans connected under EC as thermal cooling devices as well, so
these fans can then work with the thermal framework.
During the driver probing phase, we will also try to register each fan
as a thermal cooling device based on previous probe result (whether the
there are fans connected on that channel, and whether EC supports fan
control). The basic get max state, get current state, and set current
state methods are then implemented as well.
Sung-Chi Li [Thu, 11 Sep 2025 06:56:35 +0000 (06:56 +0000)]
hwmon: (cros_ec) add PWM control over fans
Newer EC firmware supports controlling fans through host commands, so
adding corresponding implementations for controlling these fans in the
driver for other kernel services and userspace to control them.
The driver will first probe the supported host command versions (get and
set of fan PWM values, get and set of fan control mode) to see if the
connected EC fulfills the requirements of controlling the fan, then
exposes corresponding sysfs nodes for userspace to control the fan with
corresponding read and write implementations.
As EC will automatically change the fan mode to auto when the device is
suspended, the power management hooks are added as well to keep the fan
control mode and fan PWM value consistent during suspend and resume. As
we need to access the hwmon device in the power management hook, update
the driver by storing the hwmon device in the driver data as well.
The Kontron SMARC-sAM67 module features an on-board house keeping uC.
It is designed to be compatible with the older sl28cpld implementation,
but has different sensors, like voltage and temperature monitoring. Add
a new compatible for that board.
Armin Wolf [Wed, 17 Sep 2025 18:10:36 +0000 (20:10 +0200)]
hwmon: (dell-smm) Add support for Dell OptiPlex 7040
The Dell OptiPlex 7040 supports the legacy SMM interface for reading
sensors and performing fan control. Whitelist this machine so that
this driver loads automatically.
Armin Wolf [Wed, 17 Sep 2025 18:10:35 +0000 (20:10 +0200)]
hwmon: (dell-smm) Add support for automatic fan mode
Many machines treat fan state 3 as some sort of automatic mode,
which is superior to the separate SMM calls for switching to
automatic fan mode for two reasons:
- the fan control mode can be controlled for each fan separately
- the current fan control mode can be retrieved from the BIOS
On some machines however, this special fan state does not exist.
Fan state 3 acts like a regular fan state on such machines or
does not exist at all. Such machines usually use separate SMM calls
for enabling/disabling automatic fan control.
Add support for it. If the machine supports separate SMM calls
for changing the fan control mode, then the other interface is
ignored.
Ben Copeland [Tue, 23 Sep 2025 19:26:56 +0000 (21:26 +0200)]
hwmon: (asus-ec-sensors) increase timeout for locking ACPI mutex
Some motherboards require more time to acquire the ACPI mutex,
causing "Failed to acquire mutex" messages to appear in the kernel log.
Increase the timeout from 500ms to 800ms to accommodate these cases.
Armin Wolf [Wed, 17 Sep 2025 18:10:34 +0000 (20:10 +0200)]
hwmon: (dell-smm) Move clamping of fan speed out of i8k_set_fan()
Currently i8k_set_fan() clamps the fan speed before performing the
SMM call to ensure that the speed is not negative and not greater than
i8k_fan_max. This however is mostly unnecessary as the hwmon and
thermal interfaces alread ensure this. Only the legacy ioctl interface
does not ensure that the fan speed passed to i8k_set_fan() does meet
the above criteria.
Move the clamping out of i8k_set_fan() and into the legacy ioctl
handler to prepare for future changes.
Armin Wolf [Wed, 17 Sep 2025 18:10:33 +0000 (20:10 +0200)]
hwmon: (dell-smm) Remove Dell Precision 490 custom config data
It turns out the second fan on the Dell Precision 490 does not
really support I8K_FAN_TURBO. Setting the fan state to 3 enables
automatic fan control, just like on the other two fans.
The reason why this was misinterpreted as turbo mode was that
the second fan normally spins faster in automatic mode than
in the previous fan states. Yet when in state 3, the fan speed
reacts to heat exposure, exposing the automatic mode setting.
Guenter Roeck [Thu, 5 Jun 2025 23:23:57 +0000 (16:23 -0700)]
hwmon: Serialize accesses in hwmon core
Implement locking in the hardware monitoring core for drivers using
the _with_info() API functions.
Most hardware monitoring drivers need to support locking to protect
against parallel accesses from userspace. With older API functions, such
locking had to be implemented in the driver code since sysfs attributes
were created by the driver. However, the _with_info() API creates sysfs
attributes in the hardware monitoring core. This makes it easy to move
the locking primitives into that code. This has the benefit of simplifying
driver code while at the same time reducing the risk of incomplete of bad
locking implementations in hardware monitoring drivers.
While this means that all accesses are forced to be synchronized, this
has little if any practical impact since accesses are expected to be low
frequency and are typically synchronized from userspace anyway since
only a single process is accessing the data. On top of that, many drivers
use regmap, which also has its own locking scheme and already serializes
accesses.
Wensheng Wang [Tue, 5 Aug 2025 10:20:19 +0000 (18:20 +0800)]
hwmon: add MP2869,MP29608,MP29612 and MP29816 series driver
Add support for MPS VR mp2869/mp2869a,mp29608/mp29608a,mp29612/mp29612a
and mp29816/mp29816a/mp29816b/mp29816c controller. This driver exposes
telemetry and limit value readings and writtings.
Add a compatible string for INA700. The chip is register compatible with
INA780 but implements different ADC ranges and thus needs a separate
compatible entry.
Cc: Christian Kahr <christian.kahr@sie.at> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> # INA780 Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Sun, 31 Aug 2025 16:39:53 +0000 (09:39 -0700)]
hwmon: (ina238) Add support for INA780
INA780 is similar to the other chips in the series, but does not
support the shunt voltage register. Shunt voltage limit registers
have been renamed to current limit registers, but are otherwise
identical.
While the chip does not directly report the shunt voltage, report
it anyway by calculating its value from the current register.
Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> # INA780 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Sun, 31 Aug 2025 16:39:53 +0000 (09:39 -0700)]
hwmon: (ina238) Only configure calibration and shunt registers if needed
Prepare for supporting chips with internal shunt resistor by only setting
calibration and shunt resistor registers if no current LSB is configured.
Do not display a log message during probe if a chip does not have shunt
and gain registers since those would otherwise display 0, and a message
just indicating that the driver was loaded would be just noise.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> # INA780 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
hwmon: (ina238) Support active-high alert polarity
All chips supported by this driver support configurable active-high
alert priority. This is already documented in the devicetree description.
Add support for it to the driver.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> # INA780 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Sun, 31 Aug 2025 16:25:16 +0000 (09:25 -0700)]
hwmon: (ina238) Add support for current limits
Since the shunt voltage register and the current register now report the
same values, use the shunt voltage limit registers to report and adjust
current limits, using the same LSB as the LSB used for the actual current
register.
Handle current register accuracy differences in separate function to
improve code readability.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> # INA780 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
hwmon: (ina238) Stop using the shunt voltage register
Since the value of the current register and the value of the shunt register
now match each other, it is no longer necessary to read the shunt voltage
register in the first place. Read the current register instead and use it
to calculate the shunt voltage.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> # INA780 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The best possible dynamic range for current measurements is achieved
if the shunt register value matches the current register value. Adjust
the calibration register as well as fixed and default shunt resistor
values accordingly to achieve this range.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> # INA780 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Sun, 31 Aug 2025 04:48:29 +0000 (21:48 -0700)]
hwmon: (ina238) Simplify voltage register accesses
Calculate voltage LSB values in the probe function and use throughout
the code.
Use a single function to read all voltages, independently of the register
width. Use the pre-calculated LSB values to convert register values to
voltages and do not rely on runtime chip specific code.
Use ROUND_CLOSEST functions instead of divide operations to reduce
rounding errors.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> # INA780 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Fri, 29 Aug 2025 00:44:17 +0000 (17:44 -0700)]
hwmon: (ina238) Pre-calculate current, power, and energy LSB
Current, power, and energy LSB do not change during runtime, so we can
pre-calculate the respective values. The power LSB can be derived from
the current LSB using the equation in the datasheets. Similar, the
energy LSB can be derived from the power LSB.
Also add support for chips with built-in shunt resistor by providing
a chip specific configuration parameter for the current LSB. The
relationship of current -> power -> energy LSB values in those chips
is the same as in chips with external shunt resistor, so configuration
parameters for power and energy LSB are not needed.
Use ROUND_CLOSEST functions instead of divide operations to reduce
rounding errors.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> # INA780 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Sun, 31 Aug 2025 00:38:51 +0000 (17:38 -0700)]
hwmon: (ina238) Rework and simplify temperature calculations
The temperature register is 16 bit wide for all chips. The decimal point
is at the same location (bit 7 = 1 degree C). That means we can use the
resolution to calculate temperatures. Do that to simplify the code.
There is only a single writeable temperature attribute, and it is very
unlikely that the chips supported by this driver will ever require another
one. That means checking for that attribute in the write function is
unnecessary. Drop the check. Rename the write function from
ina238_write_temp() to ina238_write_temp_max() to reflect that a single
attribute is written.
Also extend the accepted temperature value range to the range supported by
the chip registers. Limiting the accepted value range to the temperature
range supported by the chip would make it impossible to read an
out-of-range limit from the chip and to write the same value back into it.
This is undesirable, especially since the maximum temperature register does
contain the maximum register value after a chip reset, not the temperature
limit supported by the chip.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> # INA780 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
hwmon: (ina238) Drop pointless power attribute check on attribute writes
There is only a single writeable power attribute, and it is very unlikely
that the chips supported by this driver will ever require another one.
That means checking for that attribute during runtime is unnecessary.
Drop the check. Rename the write function from ina238_write_power() to
ina238_write_power_max() to reflect that a single attribute is written.
No functional change intended.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> # INA780 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Sun, 31 Aug 2025 21:53:58 +0000 (14:53 -0700)]
hwmon: (ina238) Drop platform data support
There are no in-tree users of ina2xx platform data. Drop
support for it. The driver already supports device properties
which can be used as alternative if needed.
Also remove reference to the non-existing shunt_resistor sysfs
attribute from the driver documentation.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> # INA780 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Thu, 29 Aug 2024 04:56:57 +0000 (21:56 -0700)]
hwmon: Introduce 64-bit energy attribute support
Many chips require 64-bit variables to display the accumulated energy,
even more so since the energy units are micro-Joule. Add new sensor type
"energy64" to support reporting the chip energy as 64-bit values.
Changing the entire hardware monitoring API is not feasible, and it is only
really necessary to support reading 64-bit values for the "energyX_input"
attribute. For this reason, keep the API as-is and use type casts on both
ends to pass 64-bit pointers when reading the accumulated energy. On the
write side (which is only useful for the energyX_enable attribute), keep
passing the written value as long.
Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> # INA780 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Marek Vasut [Thu, 4 Sep 2025 20:21:10 +0000 (22:21 +0200)]
hwmon: (pwm-fan) Implement after shutdown fan settings
Add fan-shutdown-percent property, used to describe fan RPM in percent set
during shutdown. This is used to keep the fan running at fixed RPM after
the kernel shut down, which is useful on hardware that does keep heating
itself even after the kernel did shut down, for example from some sort of
management core. The current behavior of pwm-fan is to unconditionally
stop the fan on shutdown, which is not always the safe and correct thing
to do, so let the hardware description include the expected behavior.
Marek Vasut [Thu, 4 Sep 2025 20:21:09 +0000 (22:21 +0200)]
dt-bindings: hwmon: pwm-fan: Document after shutdown fan settings
Document fan-shutdown-percent property, used to describe fan RPM in percent
set during shutdown. This is used to keep the fan running at fixed RPM after
the kernel shut down, which is useful on hardware that does keep heating
itself even after the kernel did shut down, for example from some sort of
management core.
Michael Tandy [Wed, 3 Sep 2025 18:47:36 +0000 (20:47 +0200)]
hwmon: (asus-ec-sensors) sort declarations
Sort all the declarations in the source file. Contributors are asked
to insert new entries keeping alphabetical order, but the existing
ones were not completely sorted.
dt-bindings: hwmon: ti,ina2xx: Update details for various chips
ti,maximum-expected-current-microamp, ti,shunt-gain, and shunt-resistor
properties are not supported on all chips described in this bindings file.
Update the bindings accordingly.
Flaviu Nistor [Mon, 25 Aug 2025 18:02:44 +0000 (21:02 +0300)]
hwmon: tmp102: Add support for label
Add support for label sysfs attribute similar to other hwmon devices.
This is particularly useful for systems with multiple sensors on the
same board, where identifying individual sensors is much easier since
labels can be defined via device tree.
Flaviu Nistor [Mon, 25 Aug 2025 18:02:43 +0000 (21:02 +0300)]
dt-bindings: hwmon: tmp102: Add label property
Add support for an optional label property similar to other hwmon devices.
This allows, in case of boards with multiple TMP102 sensors, to assign
distinct names to each instance.
Qianfeng Rong [Sat, 30 Aug 2025 09:51:05 +0000 (17:51 +0800)]
hwmon: (nct6775) Use int type to store negative error codes
Change the 'ret' variable from u32 to int in nct6775_asuswmi_read() to
store negative error codes or zero;
Storing the negative error codes in unsigned type, doesn't cause an issue
at runtime but can be confusing. Additionally, assigning negative error
codes to unsigned type may trigger a GCC warning when the -Wsign-conversion
flag is enabled.
Dave Hansen [Thu, 28 Aug 2025 20:17:29 +0000 (13:17 -0700)]
hwmon: (coretemp) Replace x86_model checks with VFM ones
Intel CPUs have been using Family 6 for a while. The Family-model checks
in the coretemp driver implicitly assume Family 6. With the upcoming
Family 18 and 19 models, some of these checks fall apart.
While reading the temperature target MSR, cpu_has_tjmax() performs model
checks only to determine if a device warning should be printed. Instead
of expanding the checks, get rid of the function and print the warning
once unconditionally if the MSR read fails. The checks aren't worth
preventing a single line warning to dmesg.
Update the rest of the x86_model checks with VFM ones to make them more
robust. This automatically covers the upcoming Family 18 and 19 as well
as any future extended families.
Add a code comment to reflect that none of the CPUs in Family 5 or
Family 15 set X86_FEATURE_DTHERM. The VFM checks do not impact these
CPUs since the driver does not load on them.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com> Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://lore.kernel.org/r/20250828201729.1145420-1-sohil.mehta@intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Chuande Chen [Thu, 14 Aug 2025 05:39:40 +0000 (13:39 +0800)]
hwmon: (sbtsi_temp) AMD CPU extended temperature range support
Many AMD CPUs can support this feature now. We would get a wrong CPU DIE
temperature if don't consider this. In low-temperature environments,
the CPU die temperature can drop below zero. So many platforms would like
to make extended temperature range as their default configuration.
Default temperature range (0C to 255.875C).
Extended temperature range (-49C to +206.875C).
Ref Doc: AMD V3000 PPR (Doc ID #56558).
David Ober [Thu, 7 Aug 2025 10:32:28 +0000 (06:32 -0400)]
hwmon: (lenovo-ec-sensors) Update P8 supprt
This fixes differences for the P8 system that was initially set to
the same thermal values as the P7, also adds in the PSU sensor for
all of the supported systems
Rong Zhang [Sat, 23 Aug 2025 18:04:41 +0000 (02:04 +0800)]
hwmon: (k10temp) Add device ID for Strix Halo
The device ID of Strix Halo Data Fabric Function 3 has been in the tree
since commit 0e640f0a47d8 ("x86/amd_nb: Add new PCI IDs for AMD family
0x1a"), but is somehow missing from k10temp_id_table.
Liao Yuanhong [Wed, 20 Aug 2025 13:15:08 +0000 (21:15 +0800)]
hwmon: (ltc4282) remove the use of dev_err_probe()
Logging messages that show some type of "out of memory" error are generally
unnecessary as there is a generic message and a stack dump done by the
memory subsystem. These messages generally increase kernel size without
much added value[1].
The dev_err_probe() doesn't do anything when error is '-ENOMEM'. Therefore,
remove the useless call to dev_err_probe(), and just return the value
instead.
Jean Delvare [Wed, 27 Aug 2025 09:13:44 +0000 (11:13 +0200)]
hwmon: Remove Jean Delvare from maintainers
I haven't been active in maintaining the hwmon subsystem in the last
decade, so I think it's about time to admit that I do not have the
time for this duty and update the MAINTAINERS file to reflect that.
I would like to thank Guenter Roeck for taking over and doing an
excellent work for so many years.
Merge tag 'i2c-for-6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
- i801: drop superfluous WDT entry for Birch
- rtl9300:
- fix channel number check in probe
- check data length boundaries in xfer
- drop broken SMBus quick operation
* tag 'i2c-for-6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: rtl9300: remove broken SMBus Quick operation support
i2c: rtl9300: ensure data length is within supported range
i2c: rtl9300: fix channel number bound check
i2c: i801: Hide Intel Birch Stream SoC TCO WDT
Merge tag 'edac_urgent_for_v6.17_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras
Pull EDAC fix from Borislav Petkov:
- Remove a misplaced dma_free_coherent() call in altera_edac
* tag 'edac_urgent_for_v6.17_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
EDAC/altera: Delete an inappropriate dma_free_coherent() call
Merge tag 'timers-urgent-2025-09-07' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer fix from Ingo Molnar:
"Fix a severe slowdown regression in the timer vDSO code related to the
while() loop in __iter_div_u64_rem(), when the AUX-clock is enabled"
* tag 'timers-urgent-2025-09-07' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
vdso/vsyscall: Avoid slow division loop in auxiliary clock update
Merge tag 'riscv-for-linus-6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
- LTO fix for clang when building with CONFIG_CMODEL_MEDLOW
- Fix for ACPI CPPC CSR read/write return values
- Several fixes for incorrect access widths in thread_info.cpu reads
- Fix an issue in __put_user_nocheck() that was causing the glibc
tst-socket-timestamp test to fail
- Initialize struct kexec_buf records in several kexec-related
functions, which were generating UBSAN warnings
- Two fixes for sparse warnings
* tag 'riscv-for-linus-6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: Fix sparse warning about different address spaces
riscv: Fix sparse warning in __get_user_error()
riscv: kexec: Initialize kexec_buf struct
riscv: use lw when reading int cpu in asm_per_cpu
riscv, bpf: use lw when reading int cpu in bpf_get_smp_processor_id
riscv, bpf: use lw when reading int cpu in BPF_MOV64_PERCPU_REG
riscv: uaccess: fix __put_user_nocheck for unaligned accesses
riscv: use lw when reading int cpu in new_vmalloc_check
ACPI: RISC-V: Fix FFH_CPPC_CSR error handling
riscv: Only allow LTO with CMODEL_MEDANY
Merge tag 'rust-fixes-6.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
Pull rust fixes from Miguel Ojeda:
- Two changes to prepare for the future Rust 1.91.0 release (expected
2025-10-30, currently in nightly): a target specification format
change and a renamed, soon-to-be-stabilized 'core' function.
* tag 'rust-fixes-6.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
rust: support Rust >= 1.91.0 target spec
rust: use the new name Location::file_as_c_str() in Rust >= 1.91.0
Wolfram Sang [Sat, 6 Sep 2025 08:17:35 +0000 (10:17 +0200)]
Merge tag 'i2c-host-fixes-6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux into i2c/for-current
i2c-host-fixes for v6.17-rc5
- i801: fix device IDs
- in rtl9300:
- fix channel number check in probe
- check data length boundaries in xfer
- drop unsupported SMBus quick operation
Merge tag 'perf-tools-fixes-for-v6.17-2025-09-05' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools
Pull perf tools fixes from Namhyung Kim:
"Fixes for use-after-free that resulted in segfaults after merging the
bpf tree.
Also a couple of build and test fixes"
* tag 'perf-tools-fixes-for-v6.17-2025-09-05' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools:
perf symbol-elf: Add support for the block argument for libbfd
perf test: Checking BPF metadata collection fails on version string
perf tests: Fix "PE file support" test build
perf bpf-utils: Harden get_bpf_prog_info_linear
perf bpf-utils: Constify bpil_array_desc
perf bpf-event: Fix use-after-free in synthesis
Breno Leitao [Wed, 27 Aug 2025 10:42:22 +0000 (03:42 -0700)]
riscv: kexec: Initialize kexec_buf struct
The kexec_buf structure was previously declared without initialization.
commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly")
added a field that is always read but not consistently populated by all
architectures. This un-initialized field will contain garbage.
This is also triggering a UBSAN warning when the uninitialized data was
accessed:
------------[ cut here ]------------
UBSAN: invalid-load in ./include/linux/kexec.h:210:10
load of value 252 is not a valid value for type '_Bool'
Zero-initializing kexec_buf at declaration ensures all fields are
cleanly set, preventing future instances of uninitialized memory being
used.
REG_L is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide.
The struct currently has a hole after cpu, so little endian accesses
seemed fine.
projects / users / hch / misc.git / log