- 28 Feb, 2022 40 commits
-
-
Armin Wolf authored
pwm[1-*]_auto_channels_temp is documented as an official hwmon sysfs attribute, yet there is no support for it in the new with_info-API. Fix that. Signed-off-by:
Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20220224061210.16452-2-W_Armin@gmx.deSigned-off-by:
Guenter Roeck <linux@roeck-us.net>
-
Christian Lamparter authored
The TMP125 is a 2 degree Celsius accurate Digital Temperature Sensor with a SPI interface. The temperature register is a 16-bit, read-only register. The MSB (Bit 15) is a leading zero and never set. Bits 14 to 5 are the 1+9 temperature data bits in a two's complement format. Bits 4 to 0 are useless copies of Bit 5 value and therefore ignored. This was tested on a Aerohive HiveAP-350. Bonus: lm70 supports TMP122/TMP124 as well. I added them to the Kconfig module description. Signed-off-by:
Christian Lamparter <chunkeey@gmail.com> Link: https://lore.kernel.org/r/43b19cbd4e7f51e9509e561b02b5d8d0e7079fac.1645175187.git.chunkeey@gmail.comSigned-off-by:
-
Christian Lamparter authored
From the freely available Texas Instruments' TMP125 datasheet: "The TMP125 is an SPI-compatible temperature sensor available in the tiny SOT23-6 package. Requiring no external components, the TMP125 is capable of measuring temperatures within 2 degree C of accuracy over a temperature range of −25 degree C to +85 degree C and 2.5 degree C of accuracy over −40 degree C to +125 degree C." The TMP125 is very similar to the TMP121/TMP122 series of familiar chips. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/d3538ba9beededfe3a9ad5dab4903a6a01834822.1645175187.git.chunkeey@gmail.comSigned-off-by:
-
Marcello Sylvester Bauer authored
Add regulator support for PLI1209BC Digital Supervisor. Signed-off-by:
Marcello Sylvester Bauer <sylv@sylv.io> Link: https://lore.kernel.org/r/21b0cdb6dd72654effa451d3b1636ecd07b160e9.1645435888.git.sylv@sylv.ioSigned-off-by:
-
Marcello Sylvester Bauer authored
PLI1209BC is a Digital Supervisor from Vicor Corporation. Signed-off-by:
-
Marcello Sylvester Bauer authored
Add trivial device entry for PLI1209BC Digital Supervisor from Vicor Corporation. Signed-off-by:
-
Marcello Sylvester Bauer authored
Add vendor prefix for Vicor Corporation. Signed-off-by:
-
Eddie James authored
Export the power caps data for the soft minimum power cap through hwmon. Signed-off-by:
Eddie James <eajames@linux.ibm.com> Reviewed-by:
Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20220215151022.7498-5-eajames@linux.ibm.comSigned-off-by:
-
Marcello Sylvester Bauer authored
Add regulator supply into PWBUS_REGULATOR macro. This makes it optional to define a vin-supply in DT. Not defining a supply will add a dummy regulator supply instead and only cause the following debug output: ``` Looking up vin-supply property in node [...] failed ``` Signed-off-by:
-
Armin Wolf authored
On the Dell Inspiron 3505, three temperature sensors are available through the SMM interface. However since they do not have an associated type, they are not detected. Probe for those sensors in case no type was detected. _i8k_get_temp() is used instead of i8k_get_temp() since it is sometimes faster and the result is easier to check (no -ENODATA) since we do not care about the actual temp value. Tested on a Dell Inspiron 3505. Signed-off-by:
-
Armin Wolf authored
Right now, we only use bits 0 to 7 of the fan/temp sensor number by doing number & 0xff. Passing the value as a u8 makes this step unnecessary. Also add checks to the ioctl handler since users might get confused when passing 0x00000101 does the same as passing 0x00000001. Tested on a Dell Inspiron 3505. Signed-off-by:
Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20220215191113.16640-4-W_Armin@gmx.deSigned-off-by:
-
Armin Wolf authored
Document the SMM interface as requested by Pali Rohar. Since Dell does not offer any offical documentation regarding the SMM interface, the necessary information was extracted from the dell_smm_hwmon driver and other sources. Suggested-by:
-
Armin Wolf authored
When enabling said module parameter, the driver ignores all feature blacklists on relevant models, which has the potential for strange side effects. Also there seems to be a slight chance for unsupported devices to behave badly when probed for features. In such cases, the kernel should be tainted to inform people that these issues might have been caused by the dell_smm_hwmon driver with "force" enabled. Also reword the parameter description to remind users that enabling "force" also enables blacklisted features. Tested on a Dell Inspiron 3505. Signed-off-by:
-
Eddie James authored
Add sysfs entries for DVFS due to a VRM Vdd over-temperature condition, and add the GPU throttling condition bits (such that if bit 1 is set, GPU1 is throttling). Signed-off-by:
-
Eddie James authored
BMC control applications need to check the OCC mode returned by the OCC poll response, so export it in sysfs with the other OCC-specific data. Signed-off-by:
-
Eddie James authored
BMC control applications need to check the Idle Power Saver status byte returned by the OCC poll response, so export it in sysfs with the other OCC-specific data. Signed-off-by:
-
Eugene Shalygin authored
Remove the call to dev_info() from the board detection function, which is called from probe(), not only to be in line with hwmon driver rules, but also because the message duplicates the error code returned from probe() for that case (ENODEV). Changes in: - v2: add missing newline (style). Signed-off-by:
Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20220217194318.2960472-1-eugene.shalygin@gmail.comSigned-off-by:
-
Zev Weiss authored
While these chips aren't strictly advertised as voltage regulators per se, they (aside from the lm25056) support the PMBus OPERATION command to enable and disable their outputs and have status bits for reporting various warnings and faults, and can hence usefully support all the pmbus_regulator_ops operations. Signed-off-by:
Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20220219000742.20126-1-zev@bewilderbeest.netSigned-off-by:
-
Zev Weiss authored
The various PMBus status bits don't all map perfectly to the more limited set of REGULATOR_ERROR_* flags, but there's a reasonable number where they correspond well enough. Signed-off-by:
-
Eugene Shalygin authored
All the supported mainboards are for the X86 platform Signed-off-by:
-
Eugene Shalygin authored
Merge configure_sensor_setup() into probe(). Changes: - v2: add local struct device *dev = &pdev->dev; - v3: initialize dev at declaration - v4: fix checkpatch warning - v5: fix formatting - v6: code style fixes Signed-off-by:
-
Eugene Shalygin authored
Reading DSDT code for ASUS X470-based boards (the ones served by the asus_wmi_Sensors driver), where ASUS put hardware monitoring functions into the WMI code, reveals that fan and current sensors data is unsigned. For the current sensor that was confirmed by a user who showed high enough current value for overflow. Thus let's assume that the signedness of the sensors is determined by its type and that only temperature ones provide signed numbers. Signed-off-by:
-
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:
-
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:
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 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:
-
