kernel/linux.git/drivers/hwmon, branch v5.9.12

hwmon: (pwm-fan) Fix RPM calculation

2020-11-24T12:38:53+00:00

[ Upstream commit fd8feec665fef840277515a5c2b9b7c3e3970fad ] To convert the number of pulses counted into an RPM estimation, we need to divide by the width of our measurement interval instead of multiplying by it. If the width of the measurement interval is zero we don't update the RPM value to avoid dividing by zero. We also don't need to do 64-bit division, with 32-bits we can handle a fan running at over 4 million RPM. Signed-off-by: Paul Barker Link: https://lore.kernel.org/r/20201111164643.7087-1-pbarker@konsulko.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (amd_energy) modify the visibility of the counters

2020-11-18T18:22:28+00:00

commit 60268b0e8258fdea9a3c9f4b51e161c123571db3 upstream. This patch limits the visibility to owner and groups only for the energy counters exposed through the hwmon based amd_energy driver. Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Signed-off-by: Naveen Krishna Chatradhi Link: https://lore.kernel.org/r/20201112172159.8781-1-nchatrad@amd.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

hwmon: (applesmc) Re-work SMC comms

2020-11-18T18:22:21+00:00

[ Upstream commit 4d64bb4ba5ecf4831448cdb2fe16d0ae91b2b40b ] Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()") introduced an issue whereby communication with the SMC became unreliable with write errors like : [ 120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40 [ 120.378621] applesmc: LKSB: write data fail [ 120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40 [ 120.512787] applesmc: LKSB: write data fail The original code appeared to be timing sensitive and was not reliable with the timing changes in the aforementioned commit. This patch re-factors the SMC communication to remove the timing dependencies and restore function with the changes previously committed. Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2, MacBookAir1,1, MacBookAir3,1 Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()") Reported-by: Andreas Kemnade Tested-by: Andreas Kemnade # MacBookAir6,2 Acked-by: Arnd Bergmann Signed-off-by: Brad Campbell Signed-off-by: Henrik Rydberg Link: https://lore.kernel.org/r/194a7d71-a781-765a-d177-c962ef296b90@fnarfbargle.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (pmbus/max34440) Fix OC fault limits

2020-11-05T10:51:33+00:00

commit 2b52278150c49559a472f2d6dd66f6f3b405378e upstream. The max34* family have the IOUT_OC_WARN_LIMIT and IOUT_OC_CRIT_LIMIT registers swapped. Cc: stable@vger.kernel.org Signed-off-by: Steve Foreman [groeck: Updated subject, use C comment style, tab after defines] [groeck: Added missing break; statements (by alexandru.ardelean@analog.com)] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

hwmon: (bt1-pvt) Wait for the completion with timeout

2020-10-29T09:11:10+00:00

[ Upstream commit 0ffd21d5985506d164ada9e8fff6daae8ef469a1 ] If the PVT sensor is suddenly powered down while a caller is waiting for the conversion completion, the request won't be finished and the task will hang up on this procedure until the power is back up again. Let's call the wait_for_completion_timeout() method instead to prevent that. The cached timeout is exactly what we need to predict for how long conversion could normally last. Fixes: 87976ce2825d ("hwmon: Add Baikal-T1 PVT sensor driver") Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20200920110924.19741-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (bt1-pvt) Cache current update timeout

2020-10-29T09:11:10+00:00

[ Upstream commit 0015503e5f6357f286bef34d039e43359fa4efd4 ] Instead of converting the update timeout data to the milliseconds each time on the read procedure let's preserve the currently set timeout in the dedicated driver private data cache. The cached value will be then used in the timeout read method and in the alarm-less data conversion to prevent the caller task hanging up in case if the PVT sensor is suddenly powered down. Fixes: 87976ce2825d ("hwmon: Add Baikal-T1 PVT sensor driver") Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20200920110924.19741-3-Sergey.Semin@baikalelectronics.ru Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (bt1-pvt) Test sensor power supply on probe

2020-10-29T09:11:10+00:00

[ Upstream commit a6db1561291fc0f2f9aa23bf38f381adc63e7b14 ] Baikal-T1 PVT sensor has got a dedicated power supply domain (feed up by the external GPVT/VPVT_18 pins). In case if it isn't powered up, the registers will be accessible, but the sensor conversion just won't happen. Due to that an attempt to read data from any PVT sensor will cause the task hanging up. For instance that will happen if XP11 jumper isn't installed on the Baikal-T1-based BFK3.1 board. Let's at least test whether the conversion work on the device probe procedure. By doing so will make sure that the PVT sensor is powered up at least at boot time. Fixes: 87976ce2825d ("hwmon: Add Baikal-T1 PVT sensor driver") Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20200920110924.19741-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (w83627ehf) Fix a resource leak in probe

2020-10-29T09:11:08+00:00

[ Upstream commit 18360b33a071e5883250fd1e04bfdeff8c3887a3 ] Smatch has a new check for resource leaks which found a bug in probe: drivers/hwmon/w83627ehf.c:2417 w83627ehf_probe() warn: 'res->start' not released on lines: 2412. We need to clean up if devm_hwmon_device_register_with_info() fails. Fixes: 266cd5835947 ("hwmon: (w83627ehf) convert to with_info interface") Signed-off-by: Dan Carpenter Reviewed-by: Dr. David Alan Gilbert Link: https://lore.kernel.org/r/20200921125212.GA1128194@mwanda Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

hwmon: (pmbus/max34440) Fix status register reads for MAX344{51,60,61}

2020-10-29T09:11:08+00:00

[ Upstream commit 6c094b31ea2ad773824362ba0fccb88d36f8d32d ] Starting with MAX34451, the chips of this series support STATUS_IOUT and STATUS_TEMPERATURE commands, and no longer report over-current and over-temperature status with STATUS_MFR_SPECIFIC. Fixes: 7a001dbab4ade ("hwmon: (pmbus/max34440) Add support for MAX34451.") Fixes: 50115ac9b6f35 ("hwmon: (pmbus/max34440) Add support for MAX34460 and MAX34461") Reported-by: Steve Foreman Cc: Steve Foreman Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin

Merge tag 'hwmon-for-v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging

2020-08-29T19:37:00+00:00

Pull hwmon fixes from Guenter Roeck: - Fix tempeerature scale in gsc-hwmon driver - Fix divide by 0 error in nct7904 driver - Drop non-existing attribute from pmbus/isl68137 driver - Fix status check in applesmc driver * tag 'hwmon-for-v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (gsc-hwmon) Scale temperature to millidegrees hwmon: (applesmc) check status earlier. hwmon: (nct7904) Correct divide by 0 hwmon: (pmbus/isl68137) remove READ_TEMPERATURE_1 telemetry for RAA228228