linux-stable.git/drivers/hwmon, branch v6.2.3 Linux kernel stable tree hwmon: (nct6775) Fix incorrect parenthesization in nct6775_write_fan_div() 2023-03-10T08:29:45+00:00 Zev Weiss zev@bewilderbeest.net 2023-01-02T21:28:57+00:00 8014342094442e93eabd7a445d5402b5255273f8 commit 2fbb848b65cde5b876cce52ebcb34de4aaa5a94a upstream. Commit 4ef2774511dc ("hwmon: (nct6775) Convert register access to regmap API") fumbled the shifting & masking of the fan_div values such that odd-numbered fan divisors would always be set to zero. Fix it so that we actually OR in the bits we meant to. Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Fixes: 4ef2774511dc ("hwmon: (nct6775) Convert register access to regmap API") Cc: stable@kernel.org # v5.19+ Link: https://lore.kernel.org/r/20230102212857.5670-1-zev@bewilderbeest.net Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2fbb848b65cde5b876cce52ebcb34de4aaa5a94a upstream.

Commit 4ef2774511dc ("hwmon: (nct6775) Convert register access to
regmap API") fumbled the shifting & masking of the fan_div values such
that odd-numbered fan divisors would always be set to zero.  Fix it so
that we actually OR in the bits we meant to.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Fixes: 4ef2774511dc ("hwmon: (nct6775) Convert register access to regmap API")
Cc: stable@kernel.org # v5.19+
Link: https://lore.kernel.org/r/20230102212857.5670-1-zev@bewilderbeest.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
hwmon: (peci/cputemp) Fix off-by-one in coretemp_label allocation 2023-03-10T08:29:45+00:00 Zev Weiss zev@bewilderbeest.net 2023-02-02T02:18:25+00:00 984d16e83c53bca3072281b5541e1db64cc1d30a commit f00093608fa790580da309bb9feb5108fbe7c331 upstream. The find_last_bit() call produces the index of the highest-numbered core in core_mask; because cores are numbered from zero, the number of elements we need to allocate is one more than that. Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Cc: stable@kernel.org # v5.18 Fixes: bf3608f338e9 ("hwmon: peci: Add cputemp driver") Reviewed-by: Iwona Winiarska <iwona.winiarska@intel.com> Link: https://lore.kernel.org/r/20230202021825.21486-1-zev@bewilderbeest.net Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f00093608fa790580da309bb9feb5108fbe7c331 upstream.

The find_last_bit() call produces the index of the highest-numbered
core in core_mask; because cores are numbered from zero, the number of
elements we need to allocate is one more than that.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Cc: stable@kernel.org # v5.18
Fixes: bf3608f338e9 ("hwmon: peci: Add cputemp driver")
Reviewed-by: Iwona Winiarska <iwona.winiarska@intel.com>
Link: https://lore.kernel.org/r/20230202021825.21486-1-zev@bewilderbeest.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
hwmon: (nct6775) B650/B660/X670 ASUS boards support 2023-03-10T08:29:19+00:00 Denis Pauk pauk.denis@gmail.com 2023-01-11T21:22:41+00:00 e4aacc79e1d4241610d15c63ff11a881fbc7a0dc [ Upstream commit e2e09989ccc21ad428d6393450add78584b143bd ] Boards such as: "EX-B660M-V5 PRO D4", "PRIME B650-PLUS", "PRIME B650M-A", "PRIME B650M-A AX", "PRIME B650M-A II", "PRIME B650M-A WIFI", "PRIME B650M-A WIFI II", "PRIME B660M-A D4", "PRIME B660M-A WIFI D4", "PRIME X670-P", "PRIME X670-P WIFI", "PRIME X670E-PRO WIFI", "Pro B660M-C-D4", "ProArt B660-CREATOR D4", "ProArt X670E-CREATOR WIFI", "ROG CROSSHAIR X670E EXTREME", "ROG CROSSHAIR X670E GENE", "ROG CROSSHAIR X670E HERO", "ROG MAXIMUS XIII EXTREME GLACIAL", "ROG MAXIMUS Z690 EXTREME", "ROG MAXIMUS Z690 EXTREME GLACIAL", "ROG STRIX B650-A GAMING WIFI", "ROG STRIX B650E-E GAMING WIFI", "ROG STRIX B650E-F GAMING WIFI", "ROG STRIX B650E-I GAMING WIFI", "ROG STRIX B660-A GAMING WIFI D4", "ROG STRIX B660-F GAMING WIFI", "ROG STRIX B660-G GAMING WIFI", "ROG STRIX B660-I GAMING WIFI", "ROG STRIX X670E-A GAMING WIFI", "ROG STRIX X670E-E GAMING WIFI", "ROG STRIX X670E-F GAMING WIFI", "ROG STRIX X670E-I GAMING WIFI", "ROG STRIX Z590-A GAMING WIFI II", "ROG STRIX Z690-A GAMING WIFI D4", "TUF GAMING B650-PLUS", "TUF GAMING B650-PLUS WIFI", "TUF GAMING B650M-PLUS", "TUF GAMING B650M-PLUS WIFI", "TUF GAMING B660M-PLUS WIFI", "TUF GAMING X670E-PLUS", "TUF GAMING X670E-PLUS WIFI", "TUF GAMING Z590-PLUS WIFI", have got a NCT6799D chip, but by default there's no use of it because of resource conflict with WMI method. This commit adds such boards to the monitoring list with new ACPI device UID. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807 Signed-off-by: Denis Pauk <pauk.denis@gmail.com> Co-developed-by: Ahmad Khalifa <ahmad@khalifa.ws> Signed-off-by: Ahmad Khalifa <ahmad@khalifa.ws> Tested-by: Jeroen Beerstra <jeroen@beerstra.org> Tested-by: Slawomir Stepien <sst@poczta.fm> Link: https://lore.kernel.org/r/20230111212241.7456-2-pauk.denis@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e2e09989ccc21ad428d6393450add78584b143bd ]

Boards such as:
  "EX-B660M-V5 PRO D4",
  "PRIME B650-PLUS",
  "PRIME B650M-A",
  "PRIME B650M-A AX",
  "PRIME B650M-A II",
  "PRIME B650M-A WIFI",
  "PRIME B650M-A WIFI II",
  "PRIME B660M-A D4",
  "PRIME B660M-A WIFI D4",
  "PRIME X670-P",
  "PRIME X670-P WIFI",
  "PRIME X670E-PRO WIFI",
  "Pro B660M-C-D4",
  "ProArt B660-CREATOR D4",
  "ProArt X670E-CREATOR WIFI",
  "ROG CROSSHAIR X670E EXTREME",
  "ROG CROSSHAIR X670E GENE",
  "ROG CROSSHAIR X670E HERO",
  "ROG MAXIMUS XIII EXTREME GLACIAL",
  "ROG MAXIMUS Z690 EXTREME",
  "ROG MAXIMUS Z690 EXTREME GLACIAL",
  "ROG STRIX B650-A GAMING WIFI",
  "ROG STRIX B650E-E GAMING WIFI",
  "ROG STRIX B650E-F GAMING WIFI",
  "ROG STRIX B650E-I GAMING WIFI",
  "ROG STRIX B660-A GAMING WIFI D4",
  "ROG STRIX B660-F GAMING WIFI",
  "ROG STRIX B660-G GAMING WIFI",
  "ROG STRIX B660-I GAMING WIFI",
  "ROG STRIX X670E-A GAMING WIFI",
  "ROG STRIX X670E-E GAMING WIFI",
  "ROG STRIX X670E-F GAMING WIFI",
  "ROG STRIX X670E-I GAMING WIFI",
  "ROG STRIX Z590-A GAMING WIFI II",
  "ROG STRIX Z690-A GAMING WIFI D4",
  "TUF GAMING B650-PLUS",
  "TUF GAMING B650-PLUS WIFI",
  "TUF GAMING B650M-PLUS",
  "TUF GAMING B650M-PLUS WIFI",
  "TUF GAMING B660M-PLUS WIFI",
  "TUF GAMING X670E-PLUS",
  "TUF GAMING X670E-PLUS WIFI",
  "TUF GAMING Z590-PLUS WIFI",
have got a NCT6799D chip, but by default there's no use of it
because of resource conflict with WMI method.

This commit adds such boards to the monitoring list with new ACPI device
UID.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
Co-developed-by: Ahmad Khalifa <ahmad@khalifa.ws>
Signed-off-by: Ahmad Khalifa <ahmad@khalifa.ws>
Tested-by: Jeroen Beerstra <jeroen@beerstra.org>
Tested-by: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20230111212241.7456-2-pauk.denis@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
hwmon: (nct6775) Directly call ASUS ACPI WMI method 2023-03-10T08:29:19+00:00 Denis Pauk pauk.denis@gmail.com 2023-01-11T21:22:40+00:00 edb8e4bda141f4efa4716a3338b1fd9766ac1e85 [ Upstream commit c3b3747d02f571da2543e719066a50dd966989d8 ] New ASUS B650/B660/X670 boards firmware have not exposed WMI monitoring GUID and entrypoint method WMBD could be implemented for different device UID. Implement the direct call to entrypoint method for monitoring the device UID of B550/X570 boards. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807 Signed-off-by: Denis Pauk <pauk.denis@gmail.com> Co-developed-by: Ahmad Khalifa <ahmad@khalifa.ws> Signed-off-by: Ahmad Khalifa <ahmad@khalifa.ws> Link: https://lore.kernel.org/r/20230111212241.7456-1-pauk.denis@gmail.com [groeck: Fix multi-line formatting] Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c3b3747d02f571da2543e719066a50dd966989d8 ]

New ASUS B650/B660/X670 boards firmware have not exposed WMI monitoring
GUID  and entrypoint method WMBD could be implemented for different device
UID.

Implement the direct call to entrypoint method for monitoring the device
UID of B550/X570 boards.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
Co-developed-by: Ahmad Khalifa <ahmad@khalifa.ws>
Signed-off-by: Ahmad Khalifa <ahmad@khalifa.ws>
Link: https://lore.kernel.org/r/20230111212241.7456-1-pauk.denis@gmail.com
[groeck: Fix multi-line formatting]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
hwmon: (coretemp) Simplify platform device handling 2023-03-10T08:29:19+00:00 Robin Murphy robin.murphy@arm.com 2023-01-03T11:46:20+00:00 c57a8d14d7880521150ee801d53a0a64fdffd9c8 [ Upstream commit 6d03bbff456befeccdd4d663177c4d6c75d0c4ff ] Coretemp's platform driver is unconventional. All the real work is done globally by the initcall and CPU hotplug notifiers, while the "driver" effectively just wraps an allocation and the registration of the hwmon interface in a long-winded round-trip through the driver core. The whole logic of dynamically creating and destroying platform devices to bring the interfaces up and down is error prone, since it assumes platform_device_add() will synchronously bind the driver and set drvdata before it returns, thus results in a NULL dereference if drivers_autoprobe is turned off for the platform bus. Furthermore, the unusual approach of doing that from within a CPU hotplug notifier, already commented in the code that it deadlocks suspend, also causes lockdep issues for other drivers or subsystems which may want to legitimately register a CPU hotplug notifier from a platform bus notifier. All of these issues can be solved by ripping this unusual behaviour out completely, simply tying the platform devices to the lifetime of the module itself, and directly managing the hwmon interfaces from the hotplug notifiers. There is a slight user-visible change in that /sys/bus/platform/drivers/coretemp will no longer appear, and /sys/devices/platform/coretemp.n will remain present if package n is hotplugged off, but hwmon users should really only be looking for the presence of the hwmon interfaces, whose behaviour remains unchanged. Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/ Link: https://gitlab.freedesktop.org/drm/intel/issues/6641 Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 6d03bbff456befeccdd4d663177c4d6c75d0c4ff ]

Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core.  The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.

All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.

Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
hwmon: (mlxreg-fan) Return zero speed for broken fan 2023-03-10T08:28:39+00:00 Vadim Pasternak vadimp@nvidia.com 2023-02-12T14:57:30+00:00 c51d9f7a5d43ade7539f5308b2ed21e7849fbdab [ Upstream commit a1ffd3c46267ee5c807acd780e15df9bb692223f ] Currently for broken fan driver returns value calculated based on error code (0xFF) in related fan speed register. Thus, for such fan user gets fan{n}_fault to 1 and fan{n}_input with misleading value. Add check for fan fault prior return speed value and return zero if fault is detected. Fixes: 65afb4c8e7e4 ("hwmon: (mlxreg-fan) Add support for Mellanox FAN driver") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20230212145730.24247-1-vadimp@nvidia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit a1ffd3c46267ee5c807acd780e15df9bb692223f ]

Currently for broken fan driver returns value calculated based on error
code (0xFF) in related fan speed register.
Thus, for such fan user gets fan{n}_fault to 1 and fan{n}_input with
misleading value.

Add check for fan fault prior return speed value and return zero if
fault is detected.

Fixes: 65afb4c8e7e4 ("hwmon: (mlxreg-fan) Add support for Mellanox FAN driver")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/20230212145730.24247-1-vadimp@nvidia.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
hwmon: (ltc2945) Handle error case in ltc2945_value_store 2023-03-10T08:28:37+00:00 Jonathan Cormier jcormier@criticallink.com 2023-01-26T22:32:25+00:00 bba4779cf9ee9aaeb9877460655660d1bef2072c [ Upstream commit 178b01eccfb0b8149682f61388400bd3d903dddc ] ltc2945_val_to_reg errors were not being handled which would have resulted in register being set to 0 (clamped) instead of being left alone. Fixes: 6700ce035f83 ("hwmon: Driver for Linear Technologies LTC2945") Signed-off-by: Jonathan Cormier <jcormier@criticallink.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 178b01eccfb0b8149682f61388400bd3d903dddc ]

ltc2945_val_to_reg errors were not being handled
which would have resulted in register being set to
0 (clamped) instead of being left alone.

Fixes: 6700ce035f83 ("hwmon: Driver for Linear Technologies LTC2945")

Signed-off-by: Jonathan Cormier <jcormier@criticallink.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
hwmon: (asus-ec-sensors) add missing mutex path 2023-03-10T08:28:37+00:00 Eugene Shalygin eugene.shalygin@gmail.com 2023-01-21T11:17:28+00:00 81722f9a804c5ba8fbc34b8369c048c78872966a [ Upstream commit e2de0e6abd91b05411cb1f0953115dbbbe9b11ce ] Add missing mutex path for ProArt X570-CREATOR WIFI. Fixes: de8fbac5e59e (hwmon: (asus-ec-sensors) implement locking via the ACPI global lock) Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20230121111728.168514-2-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e2de0e6abd91b05411cb1f0953115dbbbe9b11ce ]

Add missing mutex path for ProArt X570-CREATOR WIFI.

Fixes: de8fbac5e59e (hwmon: (asus-ec-sensors) implement locking via the ACPI global lock)
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20230121111728.168514-2-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
hwmon: (ftsteutates) Fix scaling of measurements 2023-03-10T08:28:27+00:00 Armin Wolf W_Armin@gmx.de 2022-12-24T04:18:53+00:00 41dbd5fa93d7d7496ef08598fe7ff07adb04a210 [ Upstream commit ca8fd8c16a8b77dfcf7f6ce52d2c863220693a78 ] A user complained that the ftsteutates driver was displaying bogus values since its introduction. This happens because the sensor measurements need to be scaled in order to produce meaningful results: - the fan speed needs to be multiplied by 60 since its in RPS - the temperature is in degrees celsius and needs an offset of 64 - the voltage is in 1/256 of 3.3V The offical datasheet says the voltage needs to be divided by 256, but this is likely an off-by-one-error, since even the BIOS devides by 255 (otherwise 3.3V could not be measured). The voltage channels additionally need a board-specific multiplier, however this can be done by the driver since its board-specific. The reason the missing scaling of measurements is the way Fujitsu used this driver when it was still out-of-tree. Back then, all scaling was done in userspace by libsensors, even the generic one. Tested on a Fujitsu DS3401-B1. Fixes: 08426eda58e0 ("hwmon: Add driver for FTS BMC chip "Teutates"") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20221224041855.83981-2-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ca8fd8c16a8b77dfcf7f6ce52d2c863220693a78 ]

A user complained that the ftsteutates driver was displaying
bogus values since its introduction. This happens because the
sensor measurements need to be scaled in order to produce
meaningful results:
- the fan speed needs to be multiplied by 60 since its in RPS
- the temperature is in degrees celsius and needs an offset of 64
- the voltage is in 1/256 of 3.3V

The offical datasheet says the voltage needs to be divided by 256,
but this is likely an off-by-one-error, since even the BIOS
devides by 255 (otherwise 3.3V could not be measured).

The voltage channels additionally need a board-specific multiplier,
however this can be done by the driver since its board-specific.

The reason the missing scaling of measurements is the way Fujitsu
used this driver when it was still out-of-tree. Back then, all
scaling was done in userspace by libsensors, even the generic one.

Tested on a Fujitsu DS3401-B1.

Fixes: 08426eda58e0 ("hwmon: Add driver for FTS BMC chip "Teutates"")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20221224041855.83981-2-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Merge tag 'hwmon-for-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging 2022-12-13T21:09:38+00:00 Linus Torvalds torvalds@linux-foundation.org 2022-12-13T21:09:38+00:00 4d03390b5cb97ea8562fcf324106c4735805d558 Pull hwmon updates from Guenter Roeck: "New drivers: - Driver for OneXPlayer mini AMD sensors - Ampere's Altra smpro-hwmon driver New chip and attribute support in existing drivers: - nct6775: Support for ASUS CROSSHAIR VIII/TUF/ProArt B550M - pmbus/ltc2978: Support for LTC7132 - aquacomputer_d5next: Support for temperature sensor offsets and flow sensor pulses - coretemp: Support for dynamic ttarget and tjmax Improvements: - Use devm_regulator_get_enable() where appropriate - Use sysfs_emit() instead of scnprintf() - Remove some useless #include <linux/hwmon-vid.h> - Include <linux/kstrtox.h> when appropriate - Use simple i2c probe - it87: Check for a valid chip before using force_id, and new new module parameter to ignore ACPI resource conflicts - jc42: Use regmap, and restore min/max/critical temperatures on resume - Add reporting power good and status to PMBus based regulators Last minute fixes: - emc2305: Fix probing of emc2301/2/3, and fix setting pwm values manually if THERMAL is enabled And various other minor fixes and improvements" * tag 'hwmon-for-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (37 commits) hwmon: (emc2305) fix pwm never being able to set lower hwmon: (emc2305) fix unable to probe emc2301/2/3 hwmon: (dell-smm) Move error message to make probing silent hwmon: use sysfs_emit() to instead of scnprintf() hwmon: (oxp-sensors) Fix pwm reading hwmon: (aquacomputer_d5next) Add support for Quadro flow sensor pulses hwmon: (pmbus/core) Implement regulator get_status hwmon: (oxp-sensors) Add AOK ZOE and Mini PRO hwmon: (gsc-hwmon) Switch to flexible array to simplify code hwmon: (pmbus) Add power good support hwmon: (nct6775) add ASUS CROSSHAIR VIII/TUF/ProArt B550M hwmon: (coretemp) Add support for dynamic ttarget hwmon: (coretemp) Add support for dynamic tjmax hwmon: (coretemp) rearrange tjmax handing code hwmon: Remove some useless #include <linux/hwmon-vid.h> hwmon: (coretemp) Remove obsolete temp_data->valid hwmon: add OneXPlayer mini AMD sensors driver hwmon: (aquacomputer_d5next) Clear up macros and comments hwmon: (it87) Add DMI table for future extensions hwmon: Include <linux/kstrtox.h> when appropriate ... 
Pull hwmon updates from Guenter Roeck:
 "New drivers:

   - Driver for OneXPlayer mini AMD sensors

   - Ampere's Altra smpro-hwmon driver

  New chip and attribute support in existing drivers:

   - nct6775: Support for ASUS CROSSHAIR VIII/TUF/ProArt B550M

   - pmbus/ltc2978: Support for LTC7132

   - aquacomputer_d5next: Support for temperature sensor offsets and
     flow sensor pulses

   - coretemp: Support for dynamic ttarget and tjmax

  Improvements:

   - Use devm_regulator_get_enable() where appropriate

   - Use sysfs_emit() instead of scnprintf()

   - Remove some useless #include <linux/hwmon-vid.h>

   - Include <linux/kstrtox.h> when appropriate

   - Use simple i2c probe

   - it87: Check for a valid chip before using force_id, and new new
     module parameter to ignore ACPI resource conflicts

   - jc42: Use regmap, and restore min/max/critical temperatures on
     resume

   - Add reporting power good and status to PMBus based regulators

  Last minute fixes:

   - emc2305: Fix probing of emc2301/2/3, and fix setting pwm values
     manually if THERMAL is enabled

  And various other minor fixes and improvements"

* tag 'hwmon-for-v6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (37 commits)
  hwmon: (emc2305) fix pwm never being able to set lower
  hwmon: (emc2305) fix unable to probe emc2301/2/3
  hwmon: (dell-smm) Move error message to make probing silent
  hwmon: use sysfs_emit() to instead of scnprintf()
  hwmon: (oxp-sensors) Fix pwm reading
  hwmon: (aquacomputer_d5next) Add support for Quadro flow sensor pulses
  hwmon: (pmbus/core) Implement regulator get_status
  hwmon: (oxp-sensors) Add AOK ZOE and Mini PRO
  hwmon: (gsc-hwmon) Switch to flexible array to simplify code
  hwmon: (pmbus) Add power good support
  hwmon: (nct6775) add ASUS CROSSHAIR VIII/TUF/ProArt B550M
  hwmon: (coretemp) Add support for dynamic ttarget
  hwmon: (coretemp) Add support for dynamic tjmax
  hwmon: (coretemp) rearrange tjmax handing code
  hwmon: Remove some useless #include <linux/hwmon-vid.h>
  hwmon: (coretemp) Remove obsolete temp_data->valid
  hwmon: add OneXPlayer mini AMD sensors driver
  hwmon: (aquacomputer_d5next) Clear up macros and comments
  hwmon: (it87) Add DMI table for future extensions
  hwmon: Include <linux/kstrtox.h> when appropriate
  ...