<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/hwmon, branch linux-rolling-stable</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2026-03-19T15:15:19Z</updated>
<entry>
<title>hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read</title>
<updated>2026-03-19T15:15:19Z</updated>
<author>
<name>Sanman Pradhan</name>
<email>psanman@juniper.net</email>
</author>
<published>2026-03-04T23:51:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=24a7b9daa103fa963b3fd37d8805b23e01621976'/>
<id>urn:sha1:24a7b9daa103fa963b3fd37d8805b23e01621976</id>
<content type='text'>
commit 25dd70a03b1f5f3aa71e1a5091ecd9cd2a13ee43 upstream.

The q54sj108a2_debugfs_read function suffers from a stack buffer overflow
due to incorrect arguments passed to bin2hex(). The function currently
passes 'data' as the destination and 'data_char' as the source.

Because bin2hex() converts each input byte into two hex characters, a
32-byte block read results in 64 bytes of output. Since 'data' is only
34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the end
of the buffer onto the stack.

Additionally, the arguments were swapped: it was reading from the
zero-initialized 'data_char' and writing to 'data', resulting in
all-zero output regardless of the actual I2C read.

Fix this by:
1. Expanding 'data_char' to 66 bytes to safely hold the hex output.
2. Correcting the bin2hex() argument order and using the actual read count.
3. Using a pointer to select the correct output buffer for the final
   simple_read_from_buffer call.

Fixes: d014538aa385 ("hwmon: (pmbus) Driver for Delta power supplies Q54SJ108A2")
Cc: stable@vger.kernel.org
Signed-off-by: Sanman Pradhan &lt;psanman@juniper.net&gt;
Link: https://lore.kernel.org/r/20260304235116.1045-1-sanman.p211993@gmail.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>hwmon: (max6639) fix inverted polarity</title>
<updated>2026-03-12T11:09:55Z</updated>
<author>
<name>Olivier Sobrie</name>
<email>olivier@sobrie.be</email>
</author>
<published>2026-03-04T21:20:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9101399418d8bb82a8eb3a651c54161aa88f4868'/>
<id>urn:sha1:9101399418d8bb82a8eb3a651c54161aa88f4868</id>
<content type='text'>
[ Upstream commit 170a4b21f49b3dcff3115b4c90758f0a0d77375a ]

According to MAX6639 documentation:

  D1: PWM Output Polarity. PWM output is low at
  100% duty cycle when this bit is set to zero. PWM
  output is high at 100% duty cycle when this bit is set
  to 1.

Up to commit 0f33272b60ed ("hwmon: (max6639) : Update hwmon init using
info structure"), the polarity was set to high (0x2) when no platform
data was set. After the patch, the polarity register wasn't set anymore
if no platform data was specified. Nowadays, since commit 7506ebcd662b
("hwmon: (max6639) : Configure based on DT property"), it is always set
to low which doesn't match with the comment above and change the
behavior compared to versions prior 0f33272b60ed.

Fixes: 0f33272b60ed ("hwmon: (max6639) : Update hwmon init using info structure")
Signed-off-by: Olivier Sobrie &lt;olivier@sobrie.be&gt;
Link: https://lore.kernel.org/r/20260304212039.570274-1-olivier@sobrie.be
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>hwmon: (it87) Check the it87_lock() return value</title>
<updated>2026-03-12T11:09:42Z</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2026-02-23T22:00:14Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=092d8354172d671c5668e5bebf98b00e186f993c'/>
<id>urn:sha1:092d8354172d671c5668e5bebf98b00e186f993c</id>
<content type='text'>
[ Upstream commit 07ed4f05bbfd2bc014974dcc4297fd3aa1cb88c0 ]

Return early in it87_resume() if it87_lock() fails instead of ignoring the
return value of that function. This patch suppresses a Clang thread-safety
warning.

Cc: Frank Crawford &lt;frank@crawford.emu.id.au&gt;
Cc: Guenter Roeck &lt;linux@roeck-us.net&gt;
Cc: Jean Delvare &lt;jdelvare@suse.com&gt;
Cc: linux-hwmon@vger.kernel.org
Fixes: 376e1a937b30 ("hwmon: (it87) Add calls to smbus_enable/smbus_disable as required")
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Link: https://lore.kernel.org/r/20260223220102.2158611-15-bart.vanassche@linux.dev
[groeck: Declare 'ret' at the beginning of it87_resume()]
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>hwmon: (aht10) Fix initialization commands for AHT20</title>
<updated>2026-03-12T11:09:41Z</updated>
<author>
<name>Hao Yu</name>
<email>haoyufine@gmail.com</email>
</author>
<published>2026-02-22T17:03:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fffc6ac6372ac763e81604a2120270f6c1dc0002'/>
<id>urn:sha1:fffc6ac6372ac763e81604a2120270f6c1dc0002</id>
<content type='text'>
[ Upstream commit b7497b5a99f54ab8dcda5b14a308385b2fb03d8d ]

According to the AHT20 datasheet (updated to V1.0 after the 2023.09
version), the initialization command for AHT20 is 0b10111110 (0xBE).
The previous sequence (0xE1) used in earlier versions is no longer
compatible with newer AHT20 sensors. Update the initialization
command to ensure the sensor is properly initialized.

While at it, use binary notation for DHT20_CMD_INIT to match the notation
used in the datasheet.

Fixes: d2abcb5cc885 ("hwmon: (aht10) Add support for compatible aht20")
Signed-off-by: Hao Yu &lt;haoyufine@gmail.com&gt;
Link: https://lore.kernel.org/r/20260222170332.1616-3-haoyufine@gmail.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>hwmon: (macsmc) Fix overflows, underflows, and sign extension</title>
<updated>2026-03-12T11:09:40Z</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2026-01-29T17:51:11Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c2cd816728292d0658c34079672fd8490ae65acc'/>
<id>urn:sha1:c2cd816728292d0658c34079672fd8490ae65acc</id>
<content type='text'>
[ Upstream commit 579b86f3c26fee97996e68c1cbfb7461711f3de3 ]

The macsmc-hwmon driver experienced several issues related to value
scaling and type conversion:

1. macsmc_hwmon_read_f32_scaled() clipped values to INT_MAX/INT_MIN.
   On 64-bit systems, hwmon supports long values, so clipping to
   32-bit range was premature and caused loss of range for high-power
   sensors. Changed it to use long and clip to LONG_MAX/LONG_MIN.
2. The overflow check in macsmc_hwmon_read_f32_scaled() used 1UL,
   which is 32-bit on some platforms. Switched to 1ULL.
3. macsmc_hwmon_read_key() used a u32 temporary variable for f32
   values. When assigned to a 64-bit long, negative values were
   zero-extended instead of sign-extended, resulting in large
   positive numbers.
4. macsmc_hwmon_read_ioft_scaled() used mult_frac() which could
   overflow during intermediate multiplication. Switched to
   mul_u64_u32_div() to handle the 64-bit multiplication safely.
5. ioft values (unsigned 48.16) could overflow long when scaled
   by 1,000,000. Added explicit clipping to LONG_MAX in the caller.
6. macsmc_hwmon_write_f32() truncated its long argument to int,
   potentially causing issues for large values.

Fix these issues by using appropriate types and helper functions.

Fixes: 785205fd8139 ("hwmon: Add Apple Silicon SMC hwmon driver")
Cc: James Calligeros &lt;jcalligeros99@gmail.com&gt;
Cc: Nathan Chancellor &lt;nathan@kernel.org&gt;
Cc: Neal Gompa &lt;neal@gompa.dev&gt;
Cc: Janne Grunau &lt;j@jannau.net&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Link: https://lore.kernel.org/r/20260129175112.3751907-3-linux@roeck-us.net
Reviewed-by: James Calligeros &lt;jcalligeros99@gmail.com&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>hwmon: (macsmc) Fix regressions in Apple Silicon SMC hwmon driver</title>
<updated>2026-03-12T11:09:40Z</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2026-01-29T17:51:10Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=625ef35b70d3883fb9a41cd5a988e64dd3e447d6'/>
<id>urn:sha1:625ef35b70d3883fb9a41cd5a988e64dd3e447d6</id>
<content type='text'>
[ Upstream commit 5dd69b864911ae3847365e8bafe7854e79fbeecb ]

The recently added macsmc-hwmon driver contained several critical
bugs in its sensor population logic and float conversion routines.

Specifically:
- The voltage sensor population loop used the wrong prefix ("volt-"
  instead of "voltage-") and incorrectly assigned sensors to the
  temperature sensor array (hwmon-&gt;temp.sensors) instead of the
  voltage sensor array (hwmon-&gt;volt.sensors). This would lead to
  out-of-bounds memory access or data corruption when both temperature
  and voltage sensors were present.
- The float conversion in macsmc_hwmon_write_f32() had flawed exponent
  logic for values &gt;= 2^24 and lacked masking for the mantissa, which
  could lead to incorrect values being written to the SMC.

Fix these issues to ensure correct sensor registration and reliable
manual fan control.

Confirm that the reported overflow in FIELD_PREP is fixed by declaring
macsmc_hwmon_write_f32() as __always_inline for a compile test.

Fixes: 785205fd8139 ("hwmon: Add Apple Silicon SMC hwmon driver")
Reported-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Closes: https://lore.kernel.org/linux-hwmon/20260119195817.GA1035354@ax162/
Cc: James Calligeros &lt;jcalligeros99@gmail.com&gt;
Cc: Nathan Chancellor &lt;nathan@kernel.org&gt;
Cc: Neal Gompa &lt;neal@gompa.dev&gt;
Cc: Janne Grunau &lt;j@jannau.net&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Tested-by: Nathan Chancellor &lt;nathan@kernel.org&gt; # build only
Link: https://lore.kernel.org/r/20260129175112.3751907-2-linux@roeck-us.net
Reviewed-by: James Calligeros &lt;jcalligeros99@gmail.com&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>hwmon: (max16065) Use READ/WRITE_ONCE to avoid compiler optimization induced race</title>
<updated>2026-03-04T12:21:36Z</updated>
<author>
<name>Gui-Dong Han</name>
<email>hanguidong02@gmail.com</email>
</author>
<published>2026-02-03T12:14:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fa08089e4d84372cb56d6f9e25d82d19b3c41a91'/>
<id>urn:sha1:fa08089e4d84372cb56d6f9e25d82d19b3c41a91</id>
<content type='text'>
[ Upstream commit 007be4327e443d79c9dd9e56dc16c36f6395d208 ]

Simply copying shared data to a local variable cannot prevent data
races. The compiler is allowed to optimize away the local copy and
re-read the shared memory, causing a Time-of-Check Time-of-Use (TOCTOU)
issue if the data changes between the check and the usage.

To enforce the use of the local variable, use READ_ONCE() when reading
the shared data and WRITE_ONCE() when updating it. Apply these macros to
the three identified locations (curr_sense, adc, and fault) where local
variables are used for error validation, ensuring the value remains
consistent.

Reported-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Closes: https://lore.kernel.org/all/6fe17868327207e8b850cf9f88b7dc58b2021f73.camel@decadent.org.uk/
Fixes: f5bae2642e3d ("hwmon: Driver for MAX16065 System Manager and compatibles")
Fixes: b8d5acdcf525 ("hwmon: (max16065) Use local variable to avoid TOCTOU")
Cc: stable@vger.kernel.org
Signed-off-by: Gui-Dong Han &lt;hanguidong02@gmail.com&gt;
Link: https://lore.kernel.org/r/20260203121443.5482-1-hanguidong02@gmail.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>hwmon: (nct7363) Fix a resource leak in nct7363_present_pwm_fanin</title>
<updated>2026-03-04T12:20:13Z</updated>
<author>
<name>Felix Gu</name>
<email>gu_0233@qq.com</email>
</author>
<published>2026-01-15T13:54:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fb99b58763a95e20b214fc1dd86837ae00a400b7'/>
<id>urn:sha1:fb99b58763a95e20b214fc1dd86837ae00a400b7</id>
<content type='text'>
[ Upstream commit 4923bbff0bcffe488b3aa76829c829bd15b02585 ]

When calling of_parse_phandle_with_args(), the caller is responsible
to call of_node_put() to release the reference of device node.
In nct7363_present_pwm_fanin, it does not release the reference,
causing a resource leak.

Signed-off-by: Felix Gu &lt;gu_0233@qq.com&gt;
Link: https://lore.kernel.org/r/tencent_9717645269E4C07D3D131F52201E12E5E10A@qq.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>hwmon: (f71882fg) Add F81968 support</title>
<updated>2026-03-04T12:20:13Z</updated>
<author>
<name>Ji-Ze Hong (Peter Hong)</name>
<email>peter_hong@fintek.com.tw</email>
</author>
<published>2025-12-23T05:10:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b1b9ba9d5a52490c5741b9a2dbd701d33938cec2'/>
<id>urn:sha1:b1b9ba9d5a52490c5741b9a2dbd701d33938cec2</id>
<content type='text'>
[ Upstream commit e4a3d6f79c9933fece64368168c46d6cf5fc2e52 ]

Add hardware monitoring support for the Fintek F81968 Super I/O chip.
It is fully compatible with F81866.

Several products share compatibility with the F81866. To better distinguish
between them, ensure that the Product ID is displayed when the device is
probed.

Signed-off-by: Ji-Ze Hong (Peter Hong) &lt;peter_hong@fintek.com.tw&gt;
Link: https://lore.kernel.org/r/20251223051040.10227-1-peter_hong@fintek.com.tw
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>hwmon: (emc2305) Fix a resource leak in emc2305_of_parse_pwm_child</title>
<updated>2026-03-04T12:20:13Z</updated>
<author>
<name>Felix Gu</name>
<email>gu_0233@qq.com</email>
</author>
<published>2026-01-15T13:51:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=32b90da7bdd0168418a6054bf156e8331d5214c1'/>
<id>urn:sha1:32b90da7bdd0168418a6054bf156e8331d5214c1</id>
<content type='text'>
[ Upstream commit 2954ce672b7623478c1cfeb69e6a6e4042a3656e ]

When calling of_parse_phandle_with_args(), the caller is responsible
to call of_node_put() to release the reference of device node.
In emc2305_of_parse_pwm_child, it does not release the reference,
causing a resource leak.

Signed-off-by: Felix Gu &lt;gu_0233@qq.com&gt;
Link: https://lore.kernel.org/r/tencent_738BA80BBF28F3440301EEE6F9E470165105@qq.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
