summaryrefslogtreecommitdiff
path: root/drivers/hwmon
AgeCommit message (Collapse)AuthorFilesLines
2022-05-23hwmon: peci-dimmpower: Add Domain ID supportIwona Winiarska1-2/+2
Change peci-dimmpower hwmon device name to use both CPU ID and Domain ID. Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
2022-05-23hwmon: peci-cpupower: Add Domain ID supportIwona Winiarska1-2/+2
Change peci-cpupower hwmon device name to use both CPU ID and Domain ID. Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
2022-05-23hwmon: peci-dimmtemp: Add Domain ID supportIwona Winiarska1-4/+4
Change peci-dimmtemp hwmon device name to use both CPU ID and Domain ID. Use the corresponding Domain ID value in PECI commands. Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
2022-05-23hwmon: peci-cputemp: Add Domain ID supportIwona Winiarska1-5/+5
Change peci-cputemp hwmon device name to use both CPU ID and Domain ID. Use the corresponding Domain ID value in PECI commands. Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
2022-05-12Merge commit '49caedb668e476c100d727f2174724e0610a2b92' of ↵Sujoy Ray9-19/+138
https://github.com/openbmc/linux into openbmc/dev-5.15-intel-bump_v5.15.36 Signed-off-by: Sujoy Ray <sujoy.ray@intel.com>
2022-04-27hwmon (occ): Retry for checksum failureEddie James1-4/+11
Due to the OCC communication design with a shared SRAM area, checkum errors are expected due to corrupted buffer from OCC communications with other system components. Therefore, retry the command twice in the event of a checksum failure. OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James <eajames@linux.ibm.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20220426154956.27205-3-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-04-18hwmon: (adm1275) Allow setting sample averagingPotin Lai1-1/+39
Current driver assume PWR_AVG and VI_AVG as 1 by default, and user needs to set sample averaging via sysfs manually. This patch parses the properties "adi,power-sample-average" and "adi,volt-curr-sample-average" from device tree, and setting sample averaging during probe. Input value must be one of value in the list [1, 2, 4, 8, 16, 32, 64, 128]. OpenBMC-Staging-Count: 1 Signed-off-by: Potin Lai <potin.lai@quantatw.com> Link: https://lore.kernel.org/r/20220302123817.27025-2-potin.lai@quantatw.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20220418091728.23051-2-potin.lai@quantatw.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-04-14Merge tag 'v5.15.34' into dev-5.15Joel Stanley2-5/+15
This is the 5.15.34 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-04-08hwmon: (pmbus) Add Vin unit off handlingBrandon Wyman2-1/+2
[ Upstream commit a5436af598779219b375c1977555c82def1c35d0 ] If there is an input undervoltage fault, reported in STATUS_INPUT command response, there is quite likely a "Unit Off For Insufficient Input Voltage" condition as well. Add a constant for bit 3 of STATUS_INPUT. Update the Vin limit attributes to include both bits in the mask for clearing faults. If an input undervoltage fault occurs, causing a unit off for insufficient input voltage, but the unit is off bit is not cleared, the STATUS_WORD will not be updated to clear the input fault condition. Including the unit is off bit (bit 3) allows for the input fault condition to completely clear. Signed-off-by: Brandon Wyman <bjwyman@gmail.com> Link: https://lore.kernel.org/r/20220317232123.2103592-1-bjwyman@gmail.com Fixes: b4ce237b7f7d3 ("hwmon: (pmbus) Introduce infrastructure to detect sensors and limit registers") [groeck: Dropped unnecessary ()] Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08hwmon: (sch56xx-common) Replace WDOG_ACTIVE with WDOG_HW_RUNNINGArmin Wolf1-1/+1
[ Upstream commit 647d6f09bea7dacf4cdb6d4ea7e3051883955297 ] 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: Guenter Roeck <linux@roeck-us.net> Fixes: fb551405c0f8 (watchdog: sch56xx: Use watchdog core) Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20220131211935.3656-5-W_Armin@gmx.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08hwmon: (pmbus) Add mutex to regulator opsPatrick Rudolph1-3/+13
[ Upstream commit 686d303ee6301261b422ea51e64833d7909a2c36 ] On PMBUS devices with multiple pages, the regulator ops need to be protected with the update mutex. This prevents accidentally changing the page in a separate thread while operating on the PMBUS_OPERATION register. Tested on Infineon xdpe11280 while a separate thread polls for sensor data. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Marcello Sylvester Bauer <sylv@sylv.io> Link: https://lore.kernel.org/r/b991506bcbf665f7af185945f70bf9d5cf04637c.1645804976.git.sylv@sylv.io Fixes: ddbb4db4ced1b ("hwmon: (pmbus) Add regulator support") Cc: Alan Tull <atull@opensource.altera.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-21hwmon: (pmbus) Add Vin unit off handlingBrandon Wyman2-1/+2
If there is an input undervoltage fault, reported in STATUS_INPUT command response, there is quite likely a "Unit Off For Insufficient Input Voltage" condition as well. Add a constant for bit 3 of STATUS_INPUT. Update the Vin limit attributes to include both bits in the mask for clearing faults. If an input undervoltage fault occurs, causing a unit off for insufficient input voltage, but the unit is off bit is not cleared, the STATUS_WORD will not be updated to clear the input fault condition. Including the unit is off bit (bit 3) allows for the input fault condition to completely clear. OpenBMC-Staging-Count: 1 Signed-off-by: Brandon Wyman <bjwyman@gmail.com> Link: https://lore.kernel.org/r/20220317232123.2103592-1-bjwyman@gmail.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-03-21hwmon: (pmbus) Clear pmbus fault/warning bits after readVikash Chandola1-0/+5
Almost all fault/warning bits in pmbus status registers remain set even after fault/warning condition are removed. As per pmbus specification these faults must be cleared by user. Modify hwmon behavior to clear fault/warning bit after fetching data if fault/warning bit was set. This allows to get fresh data in next read. OpenBMC-Staging-Count: 1 Signed-off-by: Vikash Chandola <vikash.chandola@linux.intel.com> Link: https://lore.kernel.org/r/20220222131253.2426834-1-vikash.chandola@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> (cherry picked from commit 35f165f08950a876f1b95a61d79c93678fba2fd6) Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-03-16hwmon: (pmbus) Add Renesas RAA229126 VR driverZhikui Ren3-0/+102
Added pmbus driver for the new device Renesas raa229126 voltage regulator. Signed-off-by: Zhikui Ren <zhikui.ren@intel.com>
2022-03-16hwmon: (pmbus) Clear pmbus fault/warning bits after readVikash Chandola1-0/+5
[ Upstream commit 35f165f08950a876f1b95a61d79c93678fba2fd6 ] Almost all fault/warning bits in pmbus status registers remain set even after fault/warning condition are removed. As per pmbus specification these faults must be cleared by user. Modify hwmon behavior to clear fault/warning bit after fetching data if fault/warning bit was set. This allows to get fresh data in next read. Signed-off-by: Vikash Chandola <vikash.chandola@linux.intel.com> Link: https://lore.kernel.org/r/20220222131253.2426834-1-vikash.chandola@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-11Merge commit '2befcc6bb0bb1e0a4a31391a359adcab3925b6e4' of ↵Sujoy Ray11-89/+215
https://github.com/openbmc/linux into openbmc/linux_5.15.24_bump Signed-off-by: Sujoy Ray <sujoy.ray@intel.com>
2022-03-11peci: add domain ID to peci_command() callsJason M. Bills2-0/+5
Since the new struct that includes domain ID will be used within the kernel, calls to peci_command() will use the value provided. This sets domain ID to 0 for all current peci_command() calls. Signed-off-by: Jason M. Bills <jason.m.bills@intel.com>
2022-03-11peci: add msg_len to peci_commandJason M. Bills2-12/+12
To support the new domain ID, we need to include an extra byte from userspace. This adds a length to the peci_command function so we can detect when the domain ID is sent from userspace. Signed-off-by: Jason M. Bills <jason.m.bills@intel.com>
2022-03-10hwmon: (pmbus) auto detect pmbus fan pwm modeZhikui Ren2-2/+64
PMBus device with fan controls have two possible control modes RPM and PWM. RPM mode is assumed and FANx_TARGET sensor is always created to provide read and write access of fan speed control. PWM only devices have been able to use the FANx_TARGET sensor to read commanded fan speed correctly because the pmbus core driver caches the write value and return it when the TARGET sensor is read. Recent pmbus_core driver change clears the cached value once the write to FANx_TARGET completes. Read FANx_TARGET sensor now reads from actual PMBus register. As a result, RPM mode only device, FANx_TARGET sensor always read 0. Add detection of current fan control mode during pmbus_identify and set flag PMBUS_HAVE_PWM12 and/or PMBUS_HAVE_PWM34 if PWM mode is detected. PWMx and PWMx_ENABLE sensors will be created based on these flags. Fixes: 1ae5aaf5d1c5 ("hwmon: (pmbus) Clear sensor data after chip write" Signed-off-by: Zhikui Ren <zhikui.ren@intel.com>
2022-03-08Merge tag 'v5.15.26' into dev-5.15Joel Stanley1-6/+8
This is the 5.15.26 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-03-02hwmon: Handle failure to register sensor with thermal zone correctlyGuenter Roeck1-6/+8
commit 1b5f517cca36292076d9e38fa6e33a257703e62e upstream. If an attempt is made to a sensor with a thermal zone and it fails, the call to devm_thermal_zone_of_sensor_register() may return -ENODEV. This may result in crashes similar to the following. Unable to handle kernel NULL pointer dereference at virtual address 00000000000003cd ... Internal error: Oops: 96000021 [#1] PREEMPT SMP ... pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mutex_lock+0x18/0x60 lr : thermal_zone_device_update+0x40/0x2e0 sp : ffff800014c4fc60 x29: ffff800014c4fc60 x28: ffff365ee3f6e000 x27: ffffdde218426790 x26: ffff365ee3f6e000 x25: 0000000000000000 x24: ffff365ee3f6e000 x23: ffffdde218426870 x22: ffff365ee3f6e000 x21: 00000000000003cd x20: ffff365ee8bf3308 x19: ffffffffffffffed x18: 0000000000000000 x17: ffffdde21842689c x16: ffffdde1cb7a0b7c x15: 0000000000000040 x14: ffffdde21a4889a0 x13: 0000000000000228 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000001120000 x7 : 0000000000000001 x6 : 0000000000000000 x5 : 0068000878e20f07 x4 : 0000000000000000 x3 : 00000000000003cd x2 : ffff365ee3f6e000 x1 : 0000000000000000 x0 : 00000000000003cd Call trace: mutex_lock+0x18/0x60 hwmon_notify_event+0xfc/0x110 0xffffdde1cb7a0a90 0xffffdde1cb7a0b7c irq_thread_fn+0x2c/0xa0 irq_thread+0x134/0x240 kthread+0x178/0x190 ret_from_fork+0x10/0x20 Code: d503201f d503201f d2800001 aa0103e4 (c8e47c02) Jon Hunter reports that the exact call sequence is: hwmon_notify_event() --> hwmon_thermal_notify() --> thermal_zone_device_update() --> update_temperature() --> mutex_lock() The hwmon core needs to handle all errors returned from calls to devm_thermal_zone_of_sensor_register(). If the call fails with -ENODEV, report that the sensor was not attached to a thermal zone but continue to register the hwmon device. Reported-by: Jon Hunter <jonathanh@nvidia.com> Cc: Dmitry Osipenko <digetx@gmail.com> Fixes: 1597b374af222 ("hwmon: Add notification support") Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-24hwmon: (occ) Add soft minimum power cap attributeEddie James1-3/+16
Export the power caps data for the soft minimum power cap through hwmon. OpenBMC-Staging-Count: 1 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.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-02-24hwmon: (occ) Add sysfs entries for additional extended status bitsEddie James1-0/+24
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). OpenBMC-Staging-Count: 1 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-4-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-02-24hwmon: (occ) Add sysfs entry for OCC modeEddie James2-0/+12
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. OpenBMC-Staging-Count: 1 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-3-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-02-24hwmon: (occ) Add sysfs entry for IPS (Idle Power Saver) statusEddie James2-0/+12
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. OpenBMC-Staging-Count: 1 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-2-eajames@linux.ibm.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-02-24hwmon: (pmbus) Clear pmbus fault/warning bits after readVikash Chandola1-0/+5
Almost all fault/warning bits in pmbus status registers remain set even after fault/warning condition are removed. As per pmbus specification these faults must be cleared by user. Modify hwmon behavior to clear fault/warning bit after fetching data if fault/warning bit was set. This allows to get fresh data in next read. Signed-off-by: Vikash Chandola <vikash.chandola@linux.intel.com> Link: https://lore.kernel.org/r/20220222131253.2426834-1-vikash.chandola@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> (cherry picked from commit 35f165f08950a876f1b95a61d79c93678fba2fd6)
2022-02-24Revert "hwmon: (pmbus) Clear pmbus fault/warning bits before read"Vikash Chandola1-9/+0
This reverts commit 747840ee70ac06bd8e4ebad5d0c0d25009481644. Better solution was found after conversation at linux-hwmon. Hence reverting original downstream fix in favour of upstream fix. Signed-off-by: Vikash Chandola <vikash.chandola@intel.com>
2022-02-17Merge tag 'v5.15.24' into dev-5.15Joel Stanley3-14/+22
This is the 5.15.24 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-02-16hwmon: (dell-smm) Speed up setting of fan speedArmin Wolf1-4/+8
commit c0d79987a0d82671bff374c07f2201f9bdf4aaa2 upstream. When setting the fan speed, i8k_set_fan() calls i8k_get_fan_status(), causing an unnecessary SMM call since from the two users of this function, only i8k_ioctl_unlocked() needs to know the new fan status while dell_smm_write() ignores the new fan status. Since SMM calls can be very slow while also making error reporting difficult for dell_smm_write(), remove the function call from i8k_set_fan() and call it separately in i8k_ioctl_unlocked(). Tested on a Dell Inspiron 3505. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20211021190531.17379-6-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-09hwmon: peci-cpupower: Unify energy debug print formatCezary Zwolak1-2/+2
Change energy print data to proper unsigned format. After this change all energy print data formatshould be in same unified unsigned format in peci-cpupower. Signed-off-by: Cezary Zwolak <cezary.zwolak@intel.com>
2022-02-09hwmon: peci-hwmon: Unify energy debug print formatCezary Zwolak1-2/+2
Change energy print data to proper unsigned format. After this change all energy print data format should be in same unified unsigned format in peci-hwmon. Signed-off-by: Cezary Zwolak <cezary.zwolak@intel.com>
2022-02-09hwmon: peci-hwmon: Invalid hwmon CPU energy increaseCezary Zwolak1-3/+20
During host reset CPU resets its energy counters, hwmon treats such case as proper energy read (counter overflow) and calculates invalid power consumption or energy increase. Currently hwmon is unable to determine if CPU was reset, therefore it needs to deduce CPU energy counters were reset - not overflowed. For now treat 0 value as reset value. In future proper host power state detection mechanism should be implemented in hwmon or userspace. Signed-off-by: Cezary Zwolak <cezary.zwolak@intel.com>
2022-02-07hwmon: (pmbus) Clear pmbus fault/warning bits before readVikash Chandola1-0/+9
pmbus fault and warning bits are not cleared by itself once fault/warning condition is not valid anymore. As per pmbus datasheet faults must be cleared by user. Modify hwmon behavior to clear latched status bytes if any bit in status register is high prior to returning fresh data to userspace. If fault/warning conditions are still applicable fault/warning bits will be set and we will get updated data in second read. Hwmon behavior is changed here. Now sysfs reads will reflect latest values from pmbus slave, not latched values. In case a transient warning/fault has happened in the past, it will no longer be reported to userspace. Signed-off-by: Vikash Chandola <vikash.chandola@intel.com>
2022-02-01hwmon: (adt7470) Prevent divide by zero in adt7470_fan_write()Dan Carpenter1-0/+3
[ Upstream commit c1ec0cabc36718efc7fe8b4157d41b82d08ec1d2 ] The "val" variable is controlled by the user and comes from hwmon_attr_store(). The FAN_RPM_TO_PERIOD() macro divides by "val" so a zero will crash the system. Check for that and return -EINVAL. Negatives are also invalid so return -EINVAL for those too. Fixes: fc958a61ff6d ("hwmon: (adt7470) Convert to devm_hwmon_device_register_with_info API") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-01hwmon: (lm90) Fix sysfs and udev notificationsGuenter Roeck1-6/+6
[ Upstream commit d379880d9adb9f1ada3f1266aa49ea2561328e08 ] sysfs and udev notifications need to be sent to the _alarm attributes, not to the value attributes. Fixes: 94dbd23ed88c ("hwmon: (lm90) Use hwmon_notify_event()") Cc: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-01hwmon: (lm90) Mark alert as broken for MAX6654Guenter Roeck1-0/+1
[ Upstream commit a53fff96f35763d132a36c620b183fdf11022d7a ] Experiments with MAX6654 show that its alert function is broken, similar to other chips supported by the lm90 driver. Mark it accordingly. Fixes: 229d495d8189 ("hwmon: (lm90) Add max6654 support to lm90 driver") Cc: Josh Lehan <krellan@google.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-01hwmon: (lm90) Re-enable interrupts after alert clearsGuenter Roeck1-1/+1
[ Upstream commit bc341a1a98827925082e95db174734fc8bd68af6 ] If alert handling is broken, interrupts are disabled after an alert and re-enabled after the alert clears. However, if there is an interrupt handler, this does not apply if alerts were originally disabled and enabled when the driver was loaded. In that case, interrupts will stay disabled after an alert was handled though the alert handler even after the alert condition clears. Address the situation by always re-enabling interrupts after the alert condition clears if there is an interrupt handler. Fixes: 2abdc357c55d9 ("hwmon: (lm90) Unmask hardware interrupt") Cc: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-01hwmon: (lm90) Reduce maximum conversion rate for G781Guenter Roeck1-1/+1
[ Upstream commit a66c5ed539277b9f2363bbace0dba88b85b36c26 ] According to its datasheet, G781 supports a maximum conversion rate value of 8 (62.5 ms). However, chips labeled G781 and G780 were found to only support a maximum conversion rate value of 7 (125 ms). On the other side, chips labeled G781-1 and G784 were found to support a conversion rate value of 8. There is no known means to distinguish G780 from G781 or G784; all chips report the same manufacturer ID and chip revision. Setting the conversion rate register value to 8 on chips not supporting it causes unexpected behavior since the real conversion rate is set to 0 (16 seconds) if a value of 8 is written into the conversion rate register. Limit the conversion rate register value to 7 for all G78x chips to avoid the problem. Fixes: ae544f64cc7b ("hwmon: (lm90) Add support for GMT G781") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-01hwmon: (lm90) Mark alert as broken for MAX6680Guenter Roeck1-1/+1
commit 94746b0ba479743355e0d3cc1cb9cfe3011fb8be upstream. Experiments with MAX6680 and MAX6681 show that the alert function of those chips is broken, similar to other chips supported by the lm90 driver. Mark it accordingly. Fixes: 4667bcb8d8fc ("hwmon: (lm90) Introduce chip parameter structure") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-01hwmon: (lm90) Mark alert as broken for MAX6646/6647/6649Guenter Roeck1-1/+1
commit f614629f9c1080dcc844a8430e3fb4c37ebbf05d upstream. Experiments with MAX6646 and MAX6648 show that the alert function of those chips is broken, similar to other chips supported by the lm90 driver. Mark it accordingly. Fixes: 4667bcb8d8fc ("hwmon: (lm90) Introduce chip parameter structure") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-02-01intel-peci-client: Use wr_pkg_cfg struct for write commandJason M. Bills1-5/+1
The write command is incorrectly using the rd_pkg_cfg struct for the PECI command data, which could introduce issues if the structs change in the future. This fixes the write command and the callers (only peci-hwmon.h found using grep) to send the data as a u32 and use the wr_pkg_cfg struct. Tested: Wrote the /sys/class/hwmon/hwmon13/power1_cap attribute which triggers a write command and confirmed that the data written is the same after this change. Signed-off-by: Jason M. Bills <jason.m.bills@intel.com>
2022-01-31Merge tag 'v5.15.18' into dev-5.15Joel Stanley1-1/+1
This is the 5.15.18 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-01-27hwmon: (mr75203) fix wrong power-up delay valueArseny Demidov1-1/+1
[ Upstream commit a8d6d4992ad9d92356619ac372906bd29687bb46 ] In the file mr75203.c we have a macro named POWER_DELAY_CYCLE_256, the correct value should be 0x100. The register ip_tmr is expressed in units of IP clk cycles, in accordance with the datasheet. Typical power-up delays for Temperature Sensor are 256 cycles i.e. 0x100. Fixes: 9d823351a337 ("hwmon: Add hardware monitoring driver for Moortec MR75203 PVT controller") Signed-off-by: Arseny Demidov <a.demidov@yadro.com> Link: https://lore.kernel.org/r/20211219102239.1112-1-a.demidov@yadro.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-14Merge tag 'v5.15.14' into dev-5.15Joel Stanley2-67/+110
This is the 5.15.14 stable release Signed-off-by: Joel Stanley <joel@jms.id.au>
2022-01-13hwmon: (pmbus) Add support for MPS Multi-phase mp5023Howard Chiu (邱冠睿)3-0/+76
Add support for mp5023 device from Monolithic Power Systems, Inc. (MPS) vendor. This is a Hot-Swap Controller. OpenBMC-Staging-Count: 1 Signed-off-by: Howard Chiu <howard.chiu@quantatw.com> Link: https://lore.kernel.org/r/HKAPR04MB400349AA406694FB976D78D096709@HKAPR04MB4003.apcprd04.prod.outlook.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-12-29hwmon: (lm90) Do not report 'busy' status bit as alarmGuenter Roeck1-1/+2
commit cdc5287acad9ede121924a9c9313544b80d15842 upstream. Bit 7 of the status register indicates that the chip is busy doing a conversion. It does not indicate an alarm status. Stop reporting it as alarm status bit. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-29hwmom: (lm90) Fix citical alarm status for MAX6680/MAX6681Guenter Roeck1-2/+8
commit da7dc0568491104c7acb632e9d41ddce9aaabbb1 upstream. Tests with a real chip and a closer look into the datasheet reveals that the local and remote critical alarm status bits are swapped for MAX6680/MAX6681. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-29hwmon: (lm90) Drop critical attribute support for MAX6654Guenter Roeck1-37/+49
[ Upstream commit 16ba51b5dcd3f6dde2e51d5ccc86313119dcf889 ] Tests with a real chip and a closer look into the datasheet show that MAX6654 does not support CRIT/THERM/OVERTEMP limits, so drop support of the respective attributes for this chip. Introduce LM90_HAVE_CRIT flag and use it to instantiate critical limit attributes to solve the problem. Cc: Josh Lehan <krellan@google.com> Fixes: 229d495d8189 ("hwmon: (lm90) Add max6654 support to lm90 driver") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-29hwmon: (lm90) Add basic support for TI TMP461Guenter Roeck2-16/+40
[ Upstream commit f8344f7693a25d9025a59d164450b50c6f5aa3c0 ] TMP461 is almost identical to TMP451 and was actually detected as TMP451 with the existing lm90 driver if its I2C address is 0x4c. Add support for it to the lm90 driver. At the same time, improve the chip detection function to at least try to distinguish between TMP451 and TMP461. As a side effect, this fixes commit 24333ac26d01 ("hwmon: (tmp401) use smb word operations instead of 2 smb byte operations"). TMP461 does not support word operations on temperature registers, which causes bad temperature readings with the tmp401 driver. The lm90 driver does not perform word operations on temperature registers and thus does not have this problem. Support is listed as basic because TMP461 supports a sensor resolution of 0.0625 degrees C, while the lm90 driver assumes a resolution of 0.125 degrees C. Also, the TMP461 supports negative temperatures with its default temperature range, which is not the case for similar chips supported by the lm90 and the tmp401 drivers. Those limitations will be addressed with follow-up patches. Fixes: 24333ac26d01 ("hwmon: (tmp401) use smb word operations instead of 2 smb byte operations") Reported-by: David T. Wilson <david.wilson@nasa.gov> Cc: David T. Wilson <david.wilson@nasa.gov> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-29hwmon: (lm90) Introduce flag indicating extended temperature supportGuenter Roeck1-10/+11
[ Upstream commit f347e249fcf920ad6974cbd898e2ec0b366a1c34 ] A flag indicating extended temperature support makes it easier to add support for additional chips with this functionality. Cc: David T. Wilson <david.wilson@nasa.gov> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>