- 28 Feb, 2022 40 commits
-
-
Christian Lamparter authored
Adds thermal_cooling device support to the tc654/tc655 driver. This make it possible to integrate it into a device-tree supported thermal-zone node as a cooling device. I have been using this patch as part of the Netgear WNDR4700 Centria NAS Router support within OpenWrt since 2016. Signed-off-by:
Christian Lamparter <chunkeey@gmail.com> Link: https://lore.kernel.org/r/20220213004733.2421193-1-chunkeey@gmail.comSigned-off-by:
Guenter Roeck <linux@roeck-us.net>
-
Mateusz Jończyk authored
It is not the laptops, but the /proc/i8k interface that is legacy (or so I think was the intention of the help text author). The old description was confusing, fix this. The phrase "Say Y if you intend to run this kernel on old Dell laptops or want to use userspace package i8kutils." was introduced in 2015, in commit 039ae585 ("hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k") I think that "old laptops" was about hotkey and Fn key support - this driver in the 2.4 kernels' era apparently had these capabilities (see: https://github.com/vitorafsr/i8kutils , description of "repeat_rate" kernel module parameter). Signed-off-by:
Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: Pali Rohár <pali@kernel.org> Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Mark Gross <markgross@kernel.org> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20220212125654.357408-2-mat.jonczyk@o2.plSigned-off-by:
-
Mateusz Jończyk authored
In Kconfig, inside the "Processor type and features" menu, there is the CONFIG_I8K option: "Dell i8k legacy laptop support". This is very confusing - enabling CONFIG_I8K is not required for the kernel to support old Dell laptops. This option is specific to the dell-smm-hwmon driver, which mostly exports some hardware monitoring information and allows the user to change fan speed. This option is misplaced, so move CONFIG_I8K to drivers/hwmon/Kconfig, where it belongs. Also, modify the dependency order - change select SENSORS_DELL_SMM to depends on SENSORS_DELL_SMM as it is just a configuration option of dell-smm-hwmon. This includes changing the option type from tristate to bool. It was tristate because it could select CONFIG_SENSORS_DELL_SMM=m . When running "make oldconfig" on configurations with CONFIG_SENSORS_DELL_SMM enabled , this change will result in an additional question (which could be printed several times during bisecting). I think that tidying up the configuration is worth it, though. Next patch tweaks the description of CONFIG_I8K. Signed-off-by:Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20220212125654.357408-1-mat.jonczyk@o2.plSigned-off-by:
-
Eugene Shalygin authored
A user discovered [1] the CPU Core voltage sensor, which spans 2 registers and provides output in mV. Althroug the discovery was made with a X470 chipset, the sensor is present in X570 (tested with C8H). For now simply add it to each board with the CPU current sensor present. [1] https://github.com/zeule/asus-ec-sensors/issues/12Signed-off-by:
Eugene Shalygin <eugene.shalygin@gmail.com> Tested-by:
Oleksandr Natalenko <oleksandr@natalenko.name> Tested-by:
Denis Pauk <pauk.denis@gmail.com> Link: https://lore.kernel.org/r/20220208094244.1106312-1-eugene.shalygin@gmail.comSigned-off-by:
-
Cosmin Tanislav authored
The hwmon subsystem provides means of notifying userspace about events. Use it. Signed-off-by:
Cosmin Tanislav <cosmin.tanislav@analog.com> Link: https://lore.kernel.org/r/20211221215841.2641417-8-demonsingur@gmail.com [groeck: Pass hwmon device to interrupt handler] Tested-by:
-
Cosmin Tanislav authored
Not used to do anything anymore. Signed-off-by:
-
Cosmin Tanislav authored
To simplify the core driver remove function. Signed-off-by:
-
Cosmin Tanislav authored
Describe the only available channel, implement read, write and is_visible callbacks. Also, pass name to core driver for the i2c device so that it can be used to register hwmon device. Signed-off-by:
-
Cosmin Tanislav authored
To simplify the core driver remove function. Signed-off-by:
-
Guenter Roeck authored
Using regmap lets us use the regmap subsystem for SPI vs. I2C register accesses. It lets us hide access differences in backend code and lets the common code just access registers without knowing their size. We can also use regmap for register caching. Tested-by:
-
Denis Pauk authored
Boards such as * PRIME X570-P, * ROG STRIX B550-F GAMING WIFI II, * ROG STRIX B550-XE GAMING (WI-FI), * ROG STRIX X570-E GAMING, * ROG STRIX Z390-F GAMING, * ROG STRIX Z390-H GAMING, * ROG STRIX Z390-I GAMING, * ROG STRIX Z490-A GAMING, * ROG STRIX Z490-E GAMING, * ROG STRIX Z490-F GAMING, * ROG STRIX Z490-G GAMING, * ROG STRIX Z490-G GAMING (WI-FI), * ROG STRIX Z490-H GAMING have got a nct6775 chip, but by default there's no use of it because of resource conflict with WMI method. This commit adds such boards to the WMI monitoring list. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807Signed-off-by:
Per Melin <kernel@melin.net> Tested-by:
Jaap de Haan <jaap.dehaan@freenet.de> Link: https://lore.kernel.org/r/20220207214815.10995-1-pauk.denis@gmail.comSigned-off-by:
-
Eugene Shalygin authored
Temperature sensor readings are signed, which is hinted by their blank value (oxd8, 216 as unsigned and -40 as signed). T_Sensor, Crosshair VIII Hero, and a freezer were used to confirm that. Here we read fan sensors as signed too, because with their typical values and 2-byte width, I can't tell a difference between signed and unsigned, as I don't have a high speed chipset fan. Signed-off-by:
-
Dan Carpenter authored
There is no such struct as "asus_ec_sensors", it was supposed to be "ec_sensors_data". This typo does not affect either build or runtime. Fixes: c4b1687d6897 ("hwmon: (asus-ec-sensors) add driver for ASUS EC") Signed-off-by:Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220205092015.GA612@kiliSigned-off-by:
-
Eugene Shalygin authored
The Wi-Fi variant of Crosshair VIII Hero provides the same sensors, which was tested by a Libre Hardware Monitor user [1]. [1] https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/pull/453#issuecomment-1028398487Signed-off-by:
-
Marcello Sylvester Bauer authored
Add regulator support for boards where the fan-supply have to be powered up before it can be used. Signed-off-by:
Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by:
Marcello Sylvester Bauer <sylv@sylv.io> Link: https://lore.kernel.org/r/2cb9ed600fb43cdc604799746fbde2e2942cdca6.1643299570.git.sylv@sylv.ioSigned-off-by:
-
Marcello Sylvester Bauer authored
The old Datasheet does not exist anymore. Signed-off-by:
-
Vadim Pasternak authored
Recently 'cur_state' user space 'sysfs' interface 'sysfs' has been deprecated. This interface is used in Nvidia systems for setting fan speed limit. Currently fan speed limit is set from the user space by setting 'sysfs' 'cur_state' attribute to 'max_state + n', where 'n' is required limit, for example: 15 for 50% speed limit, 20 for full fan speed enforcement. The purpose of this feature is to provides ability to limit fan speed according to some system wise considerations, like absence of some replaceable units (PSU or line cards), high system ambient temperature, unreliable transceivers temperature sensing or some other factors which indirectly impacts system's airflow. The motivation is to support fan low limit feature through 'hwmon' interface. Use 'hwmon' 'pwm' attribute for setting low limit for fan speed in case 'thermal' subsystem is configured in kernel. In this case setting fan speed through 'hwmon' will never let the 'thermal' subsystem to select a lower duty cycle than the duty cycle selected with the 'pwm' attribute. From other side, fan speed is to be updated in hardware through 'pwm' only in case the requested fan speed is above last speed set by 'thermal' subsystem, otherwise requested fan speed will be just stored with no PWM update. Signed-off-by:
Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20220126141825.13545-1-vadimp@nvidia.comSigned-off-by:
-
Eugene Shalygin authored
Deprecate the asus_wmi_ec_sensors driver in favor of the asus_ec_sensors Signed-off-by:
-
Eugene Shalygin authored
Signed-off-by:
-
Eugene Shalygin authored
This driver provides the same data as the asus_wmi_ec_sensors driver (and gets it from the same source) but does not use WMI, polling the ACPI EC directly. That provides two enhancements: sensor reading became quicker (on some systems or kernel configuration it took almost a full second to read all the sensors, that transfers less than 15 bytes of data), the driver became more flexible. The driver now relies on ACPI mutex to lock access to the EC in the same way as the WMI code does. Signed-off-by:
-
Armin Wolf authored
If the watchdog was already enabled by the BIOS after booting, the watchdog infrastructure needs to regularly send keepalives to prevent a unexpected reset. WDOG_ACTIVE only serves as an status indicator for userspace, we want to use WDOG_HW_RUNNING instead. Since my Fujitsu Esprimo P720 does not support the watchdog, this change is compile-tested only. Suggested-by:
Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20220131211935.3656-5-W_Armin@gmx.deReviewed-by:
-
Armin Wolf authored
msleep(1) will often sleep more than 20ms, slowing down sensor and watchdog reads/writes. Use usleep_range() as recommended in timers-howto.rst to fix that. Tested on a Fujitsu Esprimo P720. Signed-off-by:
-
Armin Wolf authored
This patch enables the sch56xx-common module to get automatically loaded on supported machines. If a machine supports Fujitsu's SCH56XX-based hardware monitoring solutions, it contains a "Antiope"/" Antiope" dmi onboard device in case of the sch5627 or a "Theseus"/" Theseus" dmi onboard device in case of the sch5636. Since some machines like the Esprimo C700 have a seemingly faulty DMI table containing both onboard devices, the driver still needs to probe for the individual superio chip, which in presence of at least one DMI onboard device however can be considered safe. Also add a module parameter allowing for bypassing the DMI check. Tested on a Fujitsu Esprimo P720. Signed-off-by:
-
Armin Wolf authored
Right now, when sch56xx-common has detected a SCH5627/SCH5636 superio chip, the corresponding module is not automatically loaded. Fix that by adding the necessary device tables to both modules. Tested on a Fujitsu Esprimo P720. Signed-off-by:
-
Paul Cercueil authored
The recent addition of the label attribute added some code that read the "label" device property, without checking first that "dev" was non-NULL. Fix this issue by first checking that "dev" is non-NULL. Fixes: ccd98cba6a18 ("hwmon: Add "label" attribute") Signed-off-by:Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Michael Shych authored
This patch adds support for Lattice's POWR1014 power manager IC. Read access to all the ADCs on the chip are supported through the "hwmon" "sysfs" files. The main differences of POWR1014 compared to POWR1220 are amount of VMON input lines: 10 on POWR1014 and 12 lines on POWR1220 and number of output control signals: 14 on POWR1014 and 20 on POWR1220. Signed-off-by:
Michael Shych <michaelsh@nvidia.com> Reviewed-by:
-
Michael Shych authored
Reduce code by using devm_hwmon_device_register_with_groups() API by devm_hwmon_device_register_with_info() API. The motivation is to reduce code and to allow easy support for similar devices by the same driver. Signed-off-by:
-
Michael Shych authored
Update code alignments. Signed-off-by:
-
Rob Herring authored
There's no need to complicate examples with a platform specific macro. It also complicates example parsing to figure out the number of interrupt cells in examples (based on bracketing). Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220119015514.2441231-1-robh@kernel.orgSigned-off-by:
-
Marcello Sylvester Bauer authored
Fix checkpatch issues by removing trailing whitespaces in Kconfig. Signed-off-by:
-
Denis Pauk authored
ASUS ROG STRIX B450-F GAMING II has support of the same WMI monitoring method as ASUS ROG STRIX B450-F GAMING. This commit adds "ASUS ROG STRIX B450-F GAMING II" to the list of boards that can be monitored using ASUS WMI. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807Signed-off-by:
Aleksa Savic <savicaleksa83@gmail.com> Link: https://lore.kernel.org/r/20220112214917.11662-1-pauk.denis@gmail.comSigned-off-by:
-
Anthony DeRossi authored
Asus Prime X570-Pro motherboards have a T_Sensor header that can be connected to an optional temperature probe. Signed-off-by:
Anthony DeRossi <ajderossi@gmail.com> Link: https://lore.kernel.org/r/20220111051842.25634-1-ajderossi@gmail.comSigned-off-by:
-
Armin Wolf authored
Add ABI file for informing remaining users of the deprecation of the legacy /proc/i8k interface. Signed-off-by:
-
Armin Wolf authored
Add documentation for fan_mult and fan_max. Signed-off-by:
-
Armin Wolf authored
The driver should be called dell_smm_hwmon, i8k is only an alias now. Signed-off-by:
-
Dmitry Baryshkov authored
Asus PRIME B550-PLUS motherboards have got an nct6775 chip. Its resource range is covered by the \AMW0.SHWM OpRegion, so the chip is unusable when using SIO. However ASUS WMI access works. Add PRIME B550-PLUS to the list of motherboards using ASUS WMI to read data. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220110024712.753492-1-dmitry.baryshkov@linaro.orgSigned-off-by:
-
Denis Pauk authored
ASUS Pro B550M-C/PRIME B550M-A boards have got an nct6775 chip, but by default there's no use of it because of resource conflict with WMI method. This commit adds "Pro B550M-C" and "PRIME B550M-A" to the list of boards that can be monitored using ASUS WMI. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807Signed-off-by:
Gregory P. Smith <greg@krypto.org> Tested-by:
Joel Wirāmu <jwp@redhat.com> Tested-by:
Jonathan Farrugia <jonfarr87@gmail.com> Link: https://lore.kernel.org/r/20220112215013.11694-1-pauk.denis@gmail.comSigned-off-by:
-
Paul Cercueil authored
If a label is defined in the device tree for this device add that to the device specific attributes. This is useful for userspace to be able to identify an individual device when multiple identical chips are present in the system. Signed-off-by:
-
Paul Cercueil authored
Add the "label" sysfs attribute, which can contain a descriptive label that allows to uniquely identify a device within the system. Signed-off-by:
-
Zev Weiss authored
These registers report CPU temperatures (and, depending on the system, sometimes chipset temperatures) via the TSI interface on AMD systems. They're distinct from most of the other Super-IO temperature readings (CPUTIN, SYSTIN, etc.) in that they're not a selectable source for monitoring and are in a different (higher resolution) format, but can still provide useful temperature data. Signed-off-by:
Zev Weiss <zev@bewilderbeest.net> Tested-by:
Renze Nicolai <renze@rnplus.nl> Link: https://lore.kernel.org/r/20220113164629.21924-1-zev@bewilderbeest.netTested-by:
-
