summaryrefslogtreecommitdiff
path: root/drivers/hwmon
AgeCommit message (Collapse)AuthorFilesLines
2021-07-14hwmon: (max31790) Fix fan speed reporting for fan7..12Guenter Roeck1-1/+1
[ Upstream commit cbbf244f0515af3472084f22b6213121b4a63835 ] Fans 7..12 do not have their own set of configuration registers. So far the code ignored that and read beyond the end of the configuration register range to get the tachometer period. This resulted in more or less random fan speed values for those fans. The datasheet is quite vague when it comes to defining the tachometer period for fans 7..12. Experiments confirm that the period is the same for both fans associated with a given set of configuration registers. Fixes: 54187ff9d766 ("hwmon: (max31790) Convert to use new hwmon registration API") Fixes: 195a4b4298a7 ("hwmon: Driver for Maxim MAX31790") Cc: Jan Kundrát <jan.kundrat@cesnet.cz> Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz> Cc: Václav Kubernát <kubernat@cesnet.cz> Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20210526154022.3223012-2-linux@roeck-us.net Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14hwmon: (max31722) Remove non-standard ACPI device IDsGuenter Roeck1-9/+0
[ Upstream commit 97387c2f06bcfd79d04a848d35517b32ee6dca7c ] Valid Maxim Integrated ACPI device IDs would start with MXIM, not with MAX1. On top of that, ACPI device IDs reflecting chip names are almost always invalid. Remove the invalid ACPI IDs. Fixes: 04e1e70afec6 ("hwmon: (max31722) Add support for MAX31722/MAX31723 temperature sensors") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14hwmon: (lm70) Revert "hwmon: (lm70) Add support for ACPI"Guenter Roeck1-25/+1
[ Upstream commit ac61c8aae446b9c0fe18981fe721d4a43e283ad6 ] This reverts commit b58bd4c6dfe709646ed9efcbba2a70643f9bc873. None of the ACPI IDs introduced with the reverted patch is a valid ACPI device ID. Any ACPI users of this driver are advised to use PRP0001 and a devicetree-compatible device identification. Fixes: b58bd4c6dfe7 ("hwmon: (lm70) Add support for ACPI") Cc: Andrej Picej <andpicej@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14hwmon: (lm70) Use device_get_match_data()Stephen Boyd1-15/+5
[ Upstream commit 6e09d75513d2670b7ab91ab3584fc5bcf2675a75 ] Use the more modern API to get the match data out of the of match table. This saves some code, lines, and nicely avoids referencing the match table when it is undefined with configurations where CONFIG_OF=n. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: <linux-hwmon@vger.kernel.org> [robh: rework to use device_get_match_data()] Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14hwmon: (max31790) Fix pwmX_enable attributesGuenter Roeck1-15/+26
[ Upstream commit 148c847c9e5a54b99850617bf9c143af9a344f92 ] pwmX_enable supports three possible values: 0: Fan control disabled. Duty cycle is fixed to 0% 1: Fan control enabled, pwm mode. Duty cycle is determined by values written into Target Duty Cycle registers. 2: Fan control enabled, rpm mode Duty cycle is adjusted such that fan speed matches the values in Target Count registers The current code does not do this; instead, it mixes pwm control configuration with fan speed monitoring configuration. Worse, it reports that pwm control would be disabled (pwmX_enable==0) when it is in fact enabled in pwm mode. Part of the problem may be that the chip sets the "TACH input enable" bit on its own whenever the mode bit is set to RPM mode, but that doesn't mean that "TACH input enable" accurately reflects the pwm mode. Fix it up and only handle pwm control with the pwmX_enable attributes. In the documentation, clarify that disabling pwm control (pwmX_enable=0) sets the pwm duty cycle to 0%. In the code, explain why TACH_INPUT_EN is set together with RPM_MODE. While at it, only update the configuration register if the configuration has changed, and only update the cached configuration if updating the chip configuration was successful. Cc: Jan Kundrát <jan.kundrat@cesnet.cz> Cc: Václav Kubernát <kubernat@cesnet.cz> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Václav Kubernát <kubernat@cesnet.cz> Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://lore.kernel.org/r/20210526154022.3223012-4-linux@roeck-us.net Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14hwmon: (max31790) Report correct current pwm duty cyclesGuenter Roeck1-3/+3
[ Upstream commit 897f6339893b741a5d68ae8e2475df65946041c2 ] The MAX31790 has two sets of registers for pwm duty cycles, one to request a duty cycle and one to read the actual current duty cycle. Both do not have to be the same. When reporting the pwm duty cycle to the user, the actual pwm duty cycle from pwm duty cycle registers needs to be reported. When setting it, the pwm target duty cycle needs to be written. Since we don't know the actual pwm duty cycle after a target pwm duty cycle has been written, set the valid flag to false to indicate that actual pwm duty cycle should be read from the chip instead of using cached values. Cc: Jan Kundrát <jan.kundrat@cesnet.cz> Cc: Václav Kubernát <kubernat@cesnet.cz> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Václav Kubernát <kubernat@ceesnet.cz> Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://lore.kernel.org/r/20210526154022.3223012-3-linux@roeck-us.net Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-23hwmon: (scpi-hwmon) shows the negative temperature properlyRiwen Lu1-0/+9
[ Upstream commit 78d13552346289bad4a9bf8eabb5eec5e5a321a5 ] The scpi hwmon shows the sub-zero temperature in an unsigned integer, which would confuse the users when the machine works in low temperature environment. This shows the sub-zero temperature in an signed value and users can get it properly from sensors. Signed-off-by: Riwen Lu <luriwen@kylinos.cn> Tested-by: Xin Chen <chenxin@kylinos.cn> Link: https://lore.kernel.org/r/20210604030959.736379-1-luriwen@kylinos.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-10hwmon: (pmbus/isl68137) remove READ_TEMPERATURE_3 for RAA228228Grant Peltier1-2/+2
[ Upstream commit 2a29db088c7ae7121801a0d7a60740ed2d18c4f3 ] The initial version of the RAA228228 datasheet claimed that the device supported READ_TEMPERATURE_3 but not READ_TEMPERATURE_1. It has since been discovered that the datasheet was incorrect. The RAA228228 does support READ_TEMPERATURE_1 but does not support READ_TEMPERATURE_3. Signed-off-by: Grant Peltier <grantpeltier93@gmail.com> Fixes: 51fb91ed5a6f ("hwmon: (pmbus/isl68137) remove READ_TEMPERATURE_1 telemetry for RAA228228") Link: https://lore.kernel.org/r/20210514211954.GA24646@raspberrypi Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-10hwmon: (dell-smm-hwmon) Fix index valuesArmin Wolf1-2/+2
[ Upstream commit 35d470b5fbc9f82feb77b56bb0d5d0b5cd73e9da ] When support for up to 10 temp sensors and for disabling automatic BIOS fan control was added, noone updated the index values used for disallowing fan support and fan type calls. Fix those values. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20210513154546.12430-1-W_Armin@gmx.de Fixes: 1bb46a20e73b ("hwmon: (dell-smm) Support up to 10 temp sensors") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-26Revert "hwmon: (lm80) fix a missing check of bus read in lm80 probe"Greg Kroah-Hartman1-9/+2
commit 99ae3417672a6d4a3bf68d4fc43d7c6ca074d477 upstream. This reverts commit 9aa3aa15f4c2f74f47afd6c5db4b420fadf3f315. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, it was determined that this commit is not needed at all so just revert it. Also, the call to lm80_init_client() was not properly handled, so if error handling is needed in the lm80_probe() function, then it should be done properly, not half-baked like the commit being reverted here did. Cc: Kangjie Lu <kjlu@umn.edu> Fixes: 9aa3aa15f4c2 ("hwmon: (lm80) fix a missing check of bus read in lm80 probe") Cc: stable <stable@vger.kernel.org> Acked-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20210503115736.2104747-5-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-19hwmon: (occ) Fix poll rate limitingEddie James2-3/+4
[ Upstream commit 5216dff22dc2bbbbe6f00335f9fd2879670e753b ] The poll rate limiter time was initialized at zero. This breaks the comparison in time_after if jiffies is large. Switch to storing the next update time rather than the previous time, and initialize the time when the device is probed. Fixes: c10e753d43eb ("hwmon (occ): Add sensor types and versions") Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210429151336.18980-1-eajames@linux.ibm.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14hwmon: (pmbus/pxe1610) don't bail out when not all pages are activePaul Fertser1-0/+9
[ Upstream commit f025314306ae17a3fdaf2874d7e878ce19cea363 ] Certain VRs might be configured to use only the first output channel and so the mode for the second will be 0. Handle this gracefully. Fixes: b9fa0a3acfd8 ("hwmon: (pmbus/core) Add support for vid mode detection per page bases") Signed-off-by: Paul Fertser <fercerpav@gmail.com> Link: https://lore.kernel.org/r/20210416102926.13614-1-fercerpav@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-26hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklistThomas Hebb1-0/+7
commit 4008bc7d39537bb3be166d8a3129c4980e1dd7dc upstream. It has been reported[0] that the Dell XPS 15 L502X exhibits similar freezing behavior to the other systems[1] on this blacklist. The issue was exposed by a prior change of mine to automatically load dell_smm_hwmon on a wider set of XPS models. To fix the regression, add this model to the blacklist. [0] https://bugzilla.kernel.org/show_bug.cgi?id=211081 [1] https://bugzilla.kernel.org/show_bug.cgi?id=195751 Fixes: b8a13e5e8f37 ("hwmon: (dell-smm) Use one DMI match for all XPS models") Cc: stable@vger.kernel.org Reported-by: Bob Hepple <bob.hepple@gmail.com> Tested-by: Bob Hepple <bob.hepple@gmail.com> Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Reviewed-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/a09eea7616881d40d2db2fb5fa2770dc6166bdae.1611456351.git.tommyhebb@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-19hwmon: (pwm-fan) Ensure that calculation doesn't discard big period valuesUwe Kleine-König1-1/+11
[ Upstream commit 1eda52334e6d13eb1a85f713ce06dd39342b5020 ] With MAX_PWM being defined to 255 the code unsigned long period; ... period = ctx->pwm->args.period; state.duty_cycle = DIV_ROUND_UP(pwm * (period - 1), MAX_PWM); calculates a too small value for duty_cycle if the configured period is big (either by discarding the 64 bit value ctx->pwm->args.period or by overflowing the multiplication). As this results in a too slow fan and so maybe an overheating machine better be safe than sorry and error out in .probe. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20201215092031.152243-1-u.kleine-koenig@pengutronix.de Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-01-12hwmon: (amd_energy) fix allocation of hwmon_channel_info configDavid Arcari1-1/+2
commit 84e261553e6f919bf0b4d65244599ab2b41f1da5 upstream. hwmon, specifically hwmon_num_channel_attrs, expects the config array in the hwmon_channel_info structure to be terminated by a zero entry. amd_energy does not honor this convention. As result, a KASAN warning is possible. Fix this by adding an additional entry and setting it to zero. Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy counters") Signed-off-by: David Arcari <darcari@redhat.com> Cc: Naveen Krishna Chatradhi <nchatrad@amd.com> Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: David Arcari <darcari@redhat.com> Acked-by: Naveen Krishna Chatradhi <nchatrad@amd.com> Link: https://lore.kernel.org/r/20210107144707.6927-1-darcari@redhat.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30hwmon: (ina3221) Fix PM usage counter unbalance in ina3221_write_enableZhang Qilong1-1/+1
[ Upstream commit bce776f10069c806290eaac712ba73432ae8ecd7 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. It depends on the mainline commit[PM: runtime: Add pm_runtime_resume_and_get to deal with usagecounter]. Fixes: 323aeb0eb5d9a ("hwmon: (ina3221) Add PM runtime support") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201202145320.1135614-1-zhangqilong3@huawei.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30hwmon: (k10temp) Remove support for displaying voltage and current on Zen CPUsGuenter Roeck1-98/+0
commit 0a4e668b5d52eed8026f5d717196b02b55fb2dc6 upstream. Voltages and current are reported by Zen CPUs. However, the means to do so is undocumented, changes from CPU to CPU, and the raw data is not calibrated. Calibration information is available, but again not documented. This results in less than perfect user experience, up to concerns that loading the driver might possibly damage the hardware (by reporting out-of range voltages). Effectively support for reporting voltages and current is not maintainable. Drop it. Cc: Artem S. Tashkinov <aros@gmx.com> Cc: Wei Huang <wei.huang2@amd.com> Tested-by: Wei Huang <wei.huang2@amd.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-13hwmon: (amd_energy) modify the visibility of the countersNaveen Krishna Chatradhi1-1/+1
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 <gregkh@linuxfoundation.org> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com> Link: https://lore.kernel.org/r/20201112172159.8781-1-nchatrad@amd.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-11-12hwmon: (applesmc) Re-work SMC commsBrad Campbell1-48/+82
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 <andreas@kemnade.info> Tested-by: Andreas Kemnade <andreas@kemnade.info> # MacBookAir6,2 Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Brad Campbell <brad@fnarfbargle.com> Signed-off-by: Henrik Rydberg <rydberg@bitmath.org> Link: https://lore.kernel.org/r/194a7d71-a781-765a-d177-c962ef296b90@fnarfbargle.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-11-12hwmon: (pwm-fan) Fix RPM calculationPaul Barker1-7/+9
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 <pbarker@konsulko.com> Link: https://lore.kernel.org/r/20201111164643.7087-1-pbarker@konsulko.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-11-03hwmon: (pmbus) Add mutex locking for sysfs readsRobert Hancock1-3/+10
As part of commit a919ba06979a7 ("hwmon: (pmbus) Stop caching register values"), the update of the sensor value is now triggered directly by the sensor attribute value being read from sysfs. This created (or at least made much more likely) a locking issue, since nothing protected the device page selection from being unexpectedly modified by concurrent reads. If sensor values on different pages on the same device were being concurrently read by multiple threads, this could cause spurious read errors due to the page register not reading back the same value last written, or sensor values being read from the incorrect page. Add locking of the update_lock mutex in pmbus_show_sensor and pmbus_show_samples so that these cannot result in concurrent reads from the underlying device. Fixes: a919ba06979a7 ("hwmon: (pmbus) Stop caching register values") Signed-off-by: Robert Hancock <robert.hancock@calian.com> Reviewed-by: Alex Qiu <xqiu@google.com> Link: https://lore.kernel.org/r/20201103193315.3011800-1-robert.hancock@calian.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-10-26hwmon: (pmbus/max20730) use scnprintf() instead of snprintf()Dan Carpenter1-13/+13
The snprintf() function returns the number of characters which would have been printed if there were enough space, but the scnprintf() returns the number of characters which were actually printed. If the buffer is not large enough, then using snprintf() would result in a read overflow and an information leak. Fixes: 8910c0bd533d ("hwmon: (pmbus/max20730) add device monitoring via debugfs") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20201022070824.GC2817762@mwanda Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-10-24Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds1-1/+1
Pull ARM SoC platform updates from Olof Johansson: "SoC changes, a substantial part of this is cleanup of some of the older platforms that used to have a bunch of board files. In particular: - Remove non-DT i.MX platforms that haven't seen activity in years, it's time to remove them. - A bunch of cleanup and removal of platform data for TI/OMAP platforms, moving over to genpd for power/reset control (yay!) - Major cleanup of Samsung S3C24xx and S3C64xx platforms, moving them closer to multiplatform support (not quite there yet, but getting close). There are a few other changes too, smaller fixlets, etc. For new platform support, the primary ones are: - New SoC: Hisilicon SD5203, ARM926EJ-S platform. - Cpufreq support for i.MX7ULP" * tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (121 commits) ARM: mstar: Select MStar intc ARM: stm32: Replace HTTP links with HTTPS ones ARM: debug: add UART early console support for SD5203 ARM: hisi: add support for SD5203 SoC ARM: omap3: enable off mode automatically clk: imx: imx35: Remove mx35_clocks_init() clk: imx: imx31: Remove mx31_clocks_init() clk: imx: imx27: Remove mx27_clocks_init() ARM: imx: Remove unused definitions ARM: imx35: Retrieve the IIM base address from devicetree ARM: imx3: Retrieve the AVIC base address from devicetree ARM: imx3: Retrieve the CCM base address from devicetree ARM: imx31: Retrieve the IIM base address from devicetree ARM: imx27: Retrieve the CCM base address from devicetree ARM: imx27: Retrieve the SYSCTRL base address from devicetree ARM: s3c64xx: bring back notes from removed debug-macro.S ARM: s3c24xx: fix Wunused-variable warning on !MMU ARM: samsung: fix PM debug build with DEBUG_LL but !MMU MAINTAINERS: mark linux-samsung-soc list non-moderated ARM: imx: Remove remnant board file support pieces ...
2020-10-14Merge tag 'driver-core-5.10-rc1' of ↵Linus Torvalds1-19/+9
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the "big" set of driver core patches for 5.10-rc1 They include a lot of different things, all related to the driver core and/or some driver logic: - sysfs common write functions to make it easier to audit sysfs attributes - device connection cleanups and fixes - devm helpers for a few functions - NOIO allocations for when devices are being removed - minor cleanups and fixes All have been in linux-next for a while with no reported issues" * tag 'driver-core-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (31 commits) regmap: debugfs: use semicolons rather than commas to separate statements platform/x86: intel_pmc_core: do not create a static struct device drivers core: node: Use a more typical macro definition style for ACCESS_ATTR drivers core: Use sysfs_emit for shared_cpu_map_show and shared_cpu_list_show mm: and drivers core: Convert hugetlb_report_node_meminfo to sysfs_emit drivers core: Miscellaneous changes for sysfs_emit drivers core: Reindent a couple uses around sysfs_emit drivers core: Remove strcat uses around sysfs_emit and neaten drivers core: Use sysfs_emit and sysfs_emit_at for show(device *...) functions sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output dyndbg: use keyword, arg varnames for query term pairs driver core: force NOIO allocations during unplug platform_device: switch to simpler IDA interface driver core: platform: Document return type of more functions Revert "driver core: Annotate dev_err_probe() with __must_check" Revert "test_firmware: Test platform fw loading on non-EFI systems" iio: adc: xilinx-xadc: use devm_krealloc() hwmon: pmbus: use more devres helpers devres: provide devm_krealloc() syscore: Use pm_pr_dbg() for syscore_{suspend,resume}() ...
2020-10-14Merge tag 'mfd-next-5.10' of ↵Linus Torvalds3-0/+153
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "New Drivers: - Add support for initialising shared (between children) Regmaps - Add support for Kontron SL28CPLD - Add support for ENE KB3930 Embedded Controller - Add support for Intel FPGA PAC MAX 10 BMC New Device Support: - Add support for Power to Ricoh RN5T618 - Add support for UART to Intel Lakefield - Add support for LP87524_Q1 to Texas Instruments LP87565 New Functionality: - Device Tree; ene-kb3930, sl28cpld, syscon, lp87565, lp87524-q1 - Use new helper dev_err_probe(); madera-core, stmfx, wcd934x - Use new GPIOD API; dm355evm_msp - Add wake-up capability; sprd-sc27xx-spi - Add ACPI support; kempld-core Fix-ups: - Trivial (spelling/whitespace); Kconfig, ab8500 - Fix for unused variables; khadas-mcu, kempld-core - Remove unused header file(s); mt6360-core - Use correct IRQ flags in docs; act8945a, gateworks-gsc, rohm,bd70528-pmic - Add COMPILE_TEST support; asic3, tmio_core - Add dependency on I2C; SL28CPLD Bug Fixes: - Fix memory leak(s); sm501 - Do not free regmap_config's 'name' until exit; syscon" * tag 'mfd-next-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (34 commits) mfd: kempld-core: Fix unused variable 'kempld_acpi_table' when !ACPI mfd: sl28cpld: Depend on I2C mfd: asic3: Build if COMPILE_TEST=y dt-bindings: mfd: Correct interrupt flags in examples mfd: Add ACPI support to Kontron PLD driver mfd: intel-m10-bmc: Add Intel MAX 10 BMC chip support for Intel FPGA PAC mfd: lp87565: Add LP87524-Q1 variant dt-bindings: mfd: Add LP87524-Q1 dt-bindings: mfd: lp87565: Convert to yaml mfd: mt6360: Remove unused include <linux/version.h> mfd: sm501: Fix leaks in probe() mfd: syscon: Don't free allocated name for regmap_config dt-bindings: mfd: syscon: Document Exynos3 and Exynos5433 compatibles dt-bindings: mfd: syscon: Merge Samsung Exynos Sysreg bindings dt-bindings: mfd: ab8500: Remove weird Unicode characters mfd: sprd: Add wakeup capability for PMIC IRQ mfd: intel-lpss: Add device IDs for UART ports for Lakefield mfd: dm355evm_msp: Convert LEDs to GPIO descriptor table mfd: wcd934x: Simplify with dev_err_probe() mfd: stmfx: Simplify with dev_err_probe() ...
2020-10-06hwmon: (pmbus/max20730) adjust the vout reading given voltage dividerChu Lin1-0/+18
Problem: We use voltage dividers so that the voltage presented at the voltage sense pins is confusing. We might need to convert these readings to more meaningful readings given the voltage divider. Solution: Read the voltage divider resistance from dts and convert the voltage reading to a more meaningful reading. Testing: max20730 with voltage divider Signed-off-by: Chu Lin <linchuyuan@google.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20201004031445.2321090-3-linchuyuan@google.com [groeck: Return -EINVAL instead of -ENODEV on bad deevicetree data] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-10-06hwmon: Add hardware monitoring driver for Moortec MR75203 PVT controllerRahul Tanwar3-0/+667
PVT controller (MR75203) is used to configure & control Moortec embedded analog IP which contains temprature sensor(TS), voltage monitor(VM) & process detector(PD) modules. Add hardware monitoring driver to support MR75203 PVT controller. Signed-off-by: Rahul Tanwar <rahul.tanwar@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Link: https://lore.kernel.org/r/05b59cd860d2a1aa0a68ab300829efe709645184.1601889876.git.rahul.tanwar@linux.intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-10-05hwmon: (mlxreg-fan) Fix double "Mellanox"Geert Uytterhoeven1-1/+1
Remove the duplicate "Mellanox" in the help text for the Mellanox FAN driver configuration option. Fixes: 65afb4c8e7e4e7e7 ("hwmon: (mlxreg-fan) Add support for Mellanox FAN driver") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20201005124843.26688-1-geert+renesas@glider.be Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-10-05hwmon: (pmbus/max20730) add device monitoring via debugfsUgur Usug1-1/+362
Add debugfs interface support for accessing device specific registers (MFR_VOUT_MIN, MFR_DEVSET1 and MFR_DEVSET2) and others including OPERATION, ON_OFF_CONFIG, SMB_ALERT_MASK, VOUT_MODE, VOUT_COMMAND and VOUT_MAX. Signed-off-by: Ugur Usug <ugur.usug@maximintegrated.com> Link: https://lore.kernel.org/r/MWHPR11MB1965C01083AD013C630646B2FD3B0@MWHPR11MB1965.namprd11.prod.outlook.com [groeck: Resolved conflics seen due to PMBus driver API changes] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-10-05hwmon: (pmbus/max34440) Fix OC fault limitsSteve Foreman1-0/+23
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 <foremans@google.com> [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 <linux@roeck-us.net>
2020-10-04hwmon: (bt1-pvt) Wait for the completion with timeoutSerge Semin1-1/+12
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 <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920110924.19741-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-10-04hwmon: (bt1-pvt) Cache current update timeoutSerge Semin2-39/+49
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 <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920110924.19741-3-Sergey.Semin@baikalelectronics.ru Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-10-04hwmon: (bt1-pvt) Test sensor power supply on probeSerge Semin1-0/+40
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 <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920110924.19741-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-10-04hwmon: (lm75) Add regulator supportAlban Bedel1-0/+24
Add regulator support for boards where the sensor first need to be powered up before it can be used. Signed-off-by: Alban Bedel <alban.bedel@aerq.com> Link: https://lore.kernel.org/r/20201001145738.17326-4-alban.bedel@aerq.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-10-04hwmon: Add hwmon driver for Intel MAX 10 BMCXu Yilun3-0/+346
This patch adds hwmon functionality for Intel MAX 10 BMC chip. This BMC chip connects to a set of sensor chips to monitor current, voltage, thermal and power of different components on board. The BMC firmware is responsible for sensor data sampling and recording in shared registers. Host driver reads the sensor data from these shared registers and exposes them to users as hwmon interfaces. Signed-off-by: Xu Yilun <yilun.xu@intel.com> Signed-off-by: Wu Hao <hao.wu@intel.com> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/1600669071-26235-3-git-send-email-yilun.xu@intel.com [groeck: Adjusted subject] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-10-04hwmon: (pmbus) Add support for MPS Multi-phase mp2975 controllerVadim Pasternak3-0/+779
Add support for mp295 device from Monolithic Power Systems, Inc. (MPS) vendor. This is a dual-loop, digital, multi-phase controller. This device: - Supports two power rail. - Provides 8 pulse-width modulations (PWMs), and can be configured up to 8-phase operation for rail 1 and up to 4-phase operation for rail 2. - Supports two pages 0 and 1 for telemetry and also pages 2 and 3 for configuration. - Can configured VOUT readout in direct or VID format and allows setting of different formats on rails 1 and 2. For VID the following protocols are available: VR13 mode with 5-mV DAC; VR13 mode with 10-mV DAC, IMVP9 mode with 5-mV DAC. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20200926204957.10268-2-vadimp@nvidia.com [groeck: Cleaned up a couple of error returns; fixed up API changes] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-10-04hwmon: (tmp513) fix spelling typo in commentsWang Qing1-1/+1
Modify the comment typo: "compliment" -> "complement". Signed-off-by: Wang Qing <wangqing@vivo.com> Link: https://lore.kernel.org/r/1601086116-32218-1-git-send-email-wangqing@vivo.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-10-04hwmon: (amd_energy) Improve the accumulation logicNaveen Krishna Chatradhi1-83/+44
Factor out the common code in the accumulation functions for core and socket accumulation. While at it, handle the return value of the amd_create_sensor() function. Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com> Link: https://lore.kernel.org/r/20200929105322.8919-4-nchatrad@amd.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-29hwmon: (amd_energy) optimize accumulation intervalNaveen Krishna Chatradhi1-9/+11
On a system with course grain resolution of energy unit (milli J) the accumulation thread can be executed less frequently than on the system with fine grain resolution(micro J). This patch sets the accumulation thread interval to an optimum value calculated based on the (energy unit) resolution supported by the hardware (assuming a peak wattage of 240W). Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com> Link: https://lore.kernel.org/r/20200929105322.8919-3-nchatrad@amd.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-29hwmon: (amd_energy) Move label out of accumulation structureAkshay Gupta1-6/+11
At present, core & socket labels are defined in struct sensor_accumulator This patch moves it to the amd_energy_data structure, which will help in calling memset on struct sensor_accumulator to optimize the code. Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com> Link: https://lore.kernel.org/r/20200929105322.8919-2-nchatrad@amd.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-24hwmon: (adm9240) Convert to regmapChris Packham1-79/+136
Convert the adm9240 driver to using regmap and add error handling. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20200924085102.15219-4-chris.packham@alliedtelesis.co.nz [groeck: Fixed context conflict against 'hwmon: use simple i2c probe function'] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-24hwmon: (adm9240) Create functions for updating measure and configChris Packham1-64/+138
Split the body of adm9240_update_device() into two helper functions adm9240_update_measure() and adm9240_update_config(). Although neither of the new helpers returns an error yet lay the groundwork for propagating failures through to the sysfs readers. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20200924085102.15219-3-chris.packham@alliedtelesis.co.nz Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-24hwmon: (adm9240) Use loops to avoid duplicated codeChris Packham1-12/+12
Use loops for reading temp_max and initialising FAN_MIN/TEMP_MAX rather than duplicating code. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20200924085102.15219-2-chris.packham@alliedtelesis.co.nz Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-23hwmon: (k10temp) Add support for Zen3 CPUsWei Huang1-0/+24
Zen3 thermal info is supported via a new PCI device ID. Also the voltage telemetry registers and the current factors need to be defined. k10temp driver then searches for CPU family 0x19 and configures k10temp_data accordingly. Signed-off-by: Wei Huang <wei.huang2@amd.com> Link: https://lore.kernel.org/r/20200914200715.1997757-1-wei.huang2@amd.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-23hwmon: (pmbus) Move boolean error condition check to generating codeGuenter Roeck1-5/+6
0-day rightfully complains about a sometimes uninitialized variable in pmbus_get_boolean(). drivers/hwmon/pmbus/pmbus_core.c:903:13: warning: variable 'ret' is used uninitialized whenever 'if' condition is true } else if (!s1 || !s2) { While that is technically true, it won't be hit in the field since the condition indicates a programming error. Move the check of that condition into the code generating the attribute entry, and refuse generating the attribute if the condition is true. Swap the condition check in pmbus_get_boolean() to ensure that static analyzers don't get a hiccup (because we check if s1 and s2 are NULL, static analyzers may believe that they can be NULL independently of each other). Reported-by: kernel test robot <lkp@intel.com> Cc: Alex Qiu <xqiu@google.com> Reviewed-by: Alex Qiu <xqiu@google.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-23hwmon: (pmbus) Expose PEC debugfs attributeAndrew Jeffery1-0/+39
Enable runtime debug control of whether the PEC byte is exchanged with the PMBus device. Some manufacturers have asked for the PEC to be disabled as part of debugging driver communication issues with devices. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20200910021106.2958382-1-andrew@aj.id.au [groeck: Replace %1llu with %llu] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-23hwmon: (pmbus) Stop caching register valuesGuenter Roeck1-117/+89
Caching register values can be very expensive for PMBus chips. Some modern chips may have 10 or more pages, with several sensors supported per page. For example, MAX16601 creates more than 90 sysfs attributes. Register caching for such chips is time consuming, especially if only a few attributes are read on a regular basis. For MAX16601, it was observed that it can take up to two seconds to read all attributes on a slow I2C bus. In this situation, register caching results in the opposite of its intention: It increases the number of I2C operations, in some cases substantially, and it results in large latency when trying to access individual sensor data. Drop all register caching to solve the problem. Since it is no longer necessary, drop status register mapping as part of the change, and specify status registers directly. Cc: Alex Qiu <xqiu@google.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Alex Qiu <xqiu@google.com> Tested-by: Alex Qiu <xqiu@google.com> Link: https://lore.kernel.org/r/20200904163314.259087-1-linux@roeck-us.net Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-23hwmon: (k10temp) Take out debugfs codeGuenter Roeck1-77/+1
The debugfs code was intended to aid figuring out functionality of undocumented registers. Turns out that wasn't very helpful, since register locations change too much between AMD chip revisions, and the data isn't really valuable for chips where it isn't already supported. On top of that, its existence has been used as argument for providing pseudo-API debugfs functions in other drivers. So let's just take it out. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-23hwmon: (gsc-hwmon) add fan sensorTim Harvey1-3/+29
Add a fan sensor to report RPM's from a fan tach input. Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-09-23hwmon: (k10temp) Define SVI telemetry and current factors for Zen2 CPUsWei Huang1-8/+12
The voltage telemetry registers for Zen2 are different from Zen1. Also the factors of CPU current values are changed on Zen2. Add new definitions for these register. Signed-off-by: Wei Huang <wei.huang2@amd.com> Link: https://lore.kernel.org/r/20200827054242.2347-2-wei.huang2@amd.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-19 07:16:52 +0000