summaryrefslogtreecommitdiff
path: root/drivers/hwmon
AgeCommit message (Collapse)AuthorFilesLines
2018-04-10Merge tag 'hwmon-for-linus-v4.17' of ↵Linus Torvalds10-201/+612
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon updates from Guenter Roeck: - added chip support: new Centaur CPUs, ADM1272, NCT6796D - ucd9000: added debugfs attributes, gpio support - cleanup and minor bug fixes * tag 'hwmon-for-linus-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (via-cputemp) support new centaur CPUs hwmon: (nct6775) Fix writing pwmX_mode hwmon: (lm92) Add max6635 to lm92_id[] hwmon: (pmbus/adm1275) Add support for ADM1272 hwmon: (lm92) Do not try to detect MAX6635 hwmon: (ucd9000) Add debugfs attributes to provide mfr_status hwmon: (ucd9000) Add gpio chip interface hwmon: (nct6775) Add support for NCT6796D hwmon: (nct6775) Initialize boolean variables with declaration hwmon: (nct6775) Improve fan6/pwm6 support hwmon: (nct6775) Use NUM_FAN consistently hwmon: (g762) handle cleanup with devm_add_action hwmon: (sht3x) Update data sheet URL hwmon: (sht21) Update data sheet URLs hwmon: (pmbus/adm1275) Accept negative page register values hwmon: (pmbus/max8688) Accept negative page register values
2018-03-30hwmon: (via-cputemp) support new centaur CPUsdavidwang1-13/+18
New centaur CPUs (Familiy == 7) also support this cpu temperature sensor. Signed-off-by: David Wang <davidwang@zhaoxin.com> [groeck: Dropped changelog, updated subject] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-27hwmon: (nct6775) Fix writing pwmX_modeGuenter Roeck1-5/+5
pwmX_mode is defined in the ABI as 0=DC mode, 1=pwm mode. The chip register bit is set to 1 for DC mode. This got mixed up, and writing 1 into pwmX_mode resulted in DC mode enabled. Fix it up by using the ABI definition throughout the driver for consistency. Fixes: 77eb5b3703d99 ("hwmon: (nct6775) Add support for pwm, pwm_mode, ... ") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-27Merge tag 'scmi-fixes-4.17' of ↵Arnd Bergmann1-1/+1
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers Pull "ARM SCMI fixes/cleanups for v4.17" from Sudeep Holla: Couple of fixes for build warning due to uninitialised variable and static checker warning for passing NULL pointer to PTR_ERR. It also contains cleanup suggested by Stephen Boyd in SCMI clock driver using the new devm_of_clk_add_hw_provider() API. * tag 'scmi-fixes-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: clk: scmi: use devm_of_clk_add_hw_provider() API and drop scmi_clocks_remove firmware: arm_scmi: prevent accessing rate_discrete uninitialized hwmon: (scmi) return -EINVAL when sensor information is unavailable
2018-03-22hwmon: (lm92) Add max6635 to lm92_id[]Alvaro G. M1-2/+3
Since autodetection of this chip was removed, it makes sense to add prefix max6635 so that the device can be instantiated by its actual name. Signed-off-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-22hwmon: (pmbus/adm1275) Add support for ADM1272Guenter Roeck2-3/+68
The chip is quite similar to other chips in the series, but as usual it comes with its own quirks. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-22hwmon: (lm92) Do not try to detect MAX6635Alvaro G. M1-58/+0
Maxim MAX663x family are mostly compatible with LM92, but they lack any identification register. Weakening the detect function would make it prone to false positives, and current one doesn't detect all chips. Therefore, the detect function for max6635 devices is removed in favor of explicit device instatiation. Signed-off-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-20hwmon: (scmi) return -EINVAL when sensor information is unavailableSudeep Holla1-1/+1
Passing NULL pointer to PTR_ERR will result in return value of 0 indicating success which is clearly not what it is intended here. This patch returns -EINVAL instead when the sensor information is not available. Fixes: b23688aefb8b ("hwmon: add support for sensors exported via ARM SCMI") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Cc: linux-hwmon@vger.kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-03-17hwmon: (ucd9000) Add debugfs attributes to provide mfr_statusChristopher Bostic1-1/+137
Expose the gpiN_fault fields of mfr_status as individual debugfs attributes. This provides a way for users to be easily notified of gpi faults. Also provide the whole mfr_status register in debugfs. Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-17hwmon: (ucd9000) Add gpio chip interfaceChristopher Bostic1-0/+212
Add a struct gpio_chip and define some methods so that this device's I/O can be accessed via /sys/class/gpio. Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-11hwmon: (nct6775) Add support for NCT6796DGuenter Roeck2-52/+125
NCT6796D is mostly compatible to NCT6795D. It supports an additional pwm control and fan speed channel. While we are at it, update documentation for NCT6795D. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-11hwmon: (nct6775) Initialize boolean variables with declarationGuenter Roeck1-24/+4
Initialize boolean flags in nct6775_check_fan_inputs() while declaring them instead of several times throughout the code. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-11hwmon: (nct6775) Improve fan6/pwm6 supportGuenter Roeck1-7/+30
Improve fan6/pwm6 detection on NCT6795D. Add support for fan pulses for fans 4..6 and fan min limits for fan6. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-11hwmon: (nct6775) Use NUM_FAN consistentlyGuenter Roeck1-6/+6
The size of some of the arrays using the number of fans is hardcoded. Use NUM_FAN consistently throughout the driver. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-11hwmon: (g762) handle cleanup with devm_add_actionHao Peng1-39/+14
Simplify code and use devm_add_action() to handle cleanup. Signed-off-by: Peng Hao <peng.hao2@zte.com.cn> [groeck: Dropped unnecessary dummy function and NULL check] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-11hwmon: (sht21) Update data sheet URLsDanilo Bargen1-2/+1
The previously used URLs are dead. Sensirion provides permalinks for their product datasheets at https://www.sensirion.com/en/about-us/links/. Signed-off-by: Danilo Bargen <mail@dbrgn.ch> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-11hwmon: (pmbus/adm1275) Accept negative page register valuesGuenter Roeck1-2/+2
A negative page register value means that no page needs to be selected. This is used by status register read operations and needs to be accepted. The failure to do so so results in missed status and limit registers. Fixes: da8e48ab483e1 ("hwmon: (pmbus) Always call _pmbus_read_byte in core driver") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-11hwmon: (pmbus/max8688) Accept negative page register valuesGuenter Roeck1-1/+1
A negative page register value means that no page needs to be selected. This is used by status register evaluations and needs to be accepted. Fixes: da8e48ab483e1 ("hwmon: (pmbus) Always call _pmbus_read_byte in core driver") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-03-07Merge tag 'scmi-updates-4.17' of ↵Arnd Bergmann3-0/+238
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers Pull "ARM SCMI support for v4.17" from Sudeep Holla: ARM System Control and Management Interface(SCMI)[1] is more flexible and easily extensible than any of the existing interfaces. Few existing as well as future ARM platforms provide micro-controllers to abstract various power and other system management tasks which have similar interfaces, both in terms of the functions that are provided by them, and in terms of how requests are communicated to them. There are quite a few protocols like ARM SCPI, TI SCI, QCOM RPM, Nvidia Tegra BPMP, and so on already. This specification is to standardize and avoid any further fragmentation in the design of such interface by various vendors. The current SCMI driver implementation is very basic and initial support. It lacks support for notifications, asynchronous/delayed response, perf/power statistics region and sensor register region. Mailbox is the only form of transport supported currently in the driver. SCMI supports interrupt based mailbox communication, where, on completion of the processing of a message, the caller receives an interrupt as well as polling for completion. SCMI is designed to minimize the dependency on the mailbox/transport hardware. So in terms of SCMI, each channel in the mailbox includes memory area, doorbell and completion interrupt. However the doorbell and completion interrupt is highly mailbox dependent which was bit of controversial as part of SCMI/mailbox discussions. Arnd and me discussed about the few aspects of SCMI and the mailbox framework: 1. Use of mailbox framework for doorbell type mailbox controller: - Such hardware may not require any data to be sent to signal the remote about the presence of a message. The channel will have in-built information on how to trigger the signal to the remote. There are few mailbox controller drivers which are purely doorbell based. e.g.QCOM IPC, STM, Tegra, ACPI PCC,..etc 2. Supporting other mailbox controller: - SCMI just needs a mechanism to signal the remote firmware. Such controller may need fixed message to be sent to trigger a doorbell. In such case we may need to get that data from DT and pass the same to the controller. It's not covered in the current DT binding, but can be extended as optional property in future. However handling notifications may be interesting on such mailbox, but again there is no way to interpret what the data field(remote message) means, it could be a bit mask or a number or don't-care. Arnd mentioned that he doesn't like the way the mailbox binding deals with doorbell-type hardware, but we do have quite a few precedent drivers already and changing the binding to add a data field would not make it any better, but could cause other problems. So he is happy with the status quo of SCMI implementation. [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0056a/index.html * tag 'scmi-updates-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: cpufreq: scmi: add support for fast frequency switching cpufreq: add support for CPU DVFS based on SCMI message protocol hwmon: add support for sensors exported via ARM SCMI hwmon: (core) Add hwmon_max to hwmon_sensor_types enumeration clk: add support for clocks provided by SCMI firmware: arm_scmi: add device power domain support using genpd firmware: arm_scmi: add per-protocol channels support using idr objects firmware: arm_scmi: refactor in preparation to support per-protocol channels firmware: arm_scmi: add option for polling based performance domain operations firmware: arm_scmi: add support for polling based SCMI transfers firmware: arm_scmi: probe and initialise all the supported protocols firmware: arm_scmi: add initial support for sensor protocol firmware: arm_scmi: add initial support for power protocol firmware: arm_scmi: add initial support for clock protocol firmware: arm_scmi: add initial support for performance protocol firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices firmware: arm_scmi: add common infrastructure and support for base protocol firmware: arm_scmi: add basic driver infrastructure for SCMI dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol dt-bindings: mailbox: add support for mailbox client shared memory
2018-02-28hwmon: add support for sensors exported via ARM SCMISudeep Holla3-0/+238
Create a driver to add support for SoC sensors exported by the System Control Processor (SCP) via the System Control and Management Interface (SCMI). The supported sensor types is one of voltage, temperature, current, and power. The sensor labels and values provided by the SCP are exported via the hwmon sysfs interface. Cc: linux-hwmon@vger.kernel.org Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-02-16Merge tag 'hwmon-for-linus-v4.16-rc2' of ↵Linus Torvalds1-1/+4
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fix from Guenter Roeck: "Fix bad temperature display on Ryzen/Threadripper" * tag 'hwmon-for-linus-v4.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (k10temp) Only apply temperature offset if result is positive
2018-02-15Merge branch 'x86-pti-for-linus' of ↵Linus Torvalds4-6/+6
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 PTI and Spectre related fixes and updates from Ingo Molnar: "Here's the latest set of Spectre and PTI related fixes and updates: Spectre: - Add entry code register clearing to reduce the Spectre attack surface - Update the Spectre microcode blacklist - Inline the KVM Spectre helpers to get close to v4.14 performance again. - Fix indirect_branch_prediction_barrier() - Fix/improve Spectre related kernel messages - Fix array_index_nospec_mask() asm constraint - KVM: fix two MSR handling bugs PTI: - Fix a paranoid entry PTI CR3 handling bug - Fix comments objtool: - Fix paranoid_entry() frame pointer warning - Annotate WARN()-related UD2 as reachable - Various fixes - Add Add Peter Zijlstra as objtool co-maintainer Misc: - Various x86 entry code self-test fixes - Improve/simplify entry code stack frame generation and handling after recent heavy-handed PTI and Spectre changes. (There's two more WIP improvements expected here.) - Type fix for cache entries There's also some low risk non-fix changes I've included in this branch to reduce backporting conflicts: - rename a confusing x86_cpu field name - de-obfuscate the naming of single-TLB flushing primitives" * 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (41 commits) x86/entry/64: Fix CR3 restore in paranoid_exit() x86/cpu: Change type of x86_cache_size variable to unsigned int x86/spectre: Fix an error message x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping selftests/x86/mpx: Fix incorrect bounds with old _sigfault x86/mm: Rename flush_tlb_single() and flush_tlb_one() to __flush_tlb_one_[user|kernel]() x86/speculation: Add <asm/msr-index.h> dependency nospec: Move array_index_nospec() parameter checking into separate macro x86/speculation: Fix up array_index_nospec_mask() asm constraint x86/debug: Use UD2 for WARN() x86/debug, objtool: Annotate WARN()-related UD2 as reachable objtool: Fix segfault in ignore_unreachable_insn() selftests/x86: Disable tests requiring 32-bit support on pure 64-bit systems selftests/x86: Do not rely on "int $0x80" in single_step_syscall.c selftests/x86: Do not rely on "int $0x80" in test_mremap_vdso.c selftests/x86: Fix build bug caused by the 5lvl test which has been moved to the VM directory selftests/x86/pkeys: Remove unused functions selftests/x86: Clean up and document sscanf() usage selftests/x86: Fix vDSO selftest segfault for vsyscall=none x86/entry/64: Remove the unused 'icebp' macro ...
2018-02-15x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_steppingJia Zhang4-6/+6
x86_mask is a confusing name which is hard to associate with the processor's stepping. Additionally, correct an indent issue in lib/cpu.c. Signed-off-by: Jia Zhang <qianyue.zj@alibaba-inc.com> [ Updated it to more recent kernels. ] Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bp@alien8.de Cc: tony.luck@intel.com Link: http://lkml.kernel.org/r/1514771530-70829-1-git-send-email-qianyue.zj@alibaba-inc.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-13hwmon: (k10temp) Only apply temperature offset if result is positiveGuenter Roeck1-1/+4
A user reports a really bad temperature on Ryzen 1950X. k10temp-pci-00cb Adapter: PCI adapter temp1: +4294948.3°C (high = +70.0°C) This will happen if the temperature reported by the chip is lower than the offset temperature. This has been seen in the field if "Sense MI Skew" and/or "Sense MI Offset" BIOS parameters were set to unexpected values. Let's report a temperature of 0 degrees C in that case. Fixes: 1b50b776355f ("hwmon: (k10temp) Add support for temperature offsets") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-27hwmon: (dell-smm) Disable fan support for Dell Vostro 3360Oleksandr Natalenko1-0/+7
Calling fan related SMM functions implemented by Dell BIOS firmware on Dell Vostro 3360 freeze kernel for about 500ms. Unfortunately, it is unlikely for Dell to fix this since the machine is pretty old, so this commit just disables fan support to make the system usable again. Via "force" module param fan support can be enabled. Link: https://bugzilla.kernel.org/show_bug.cgi?id=195751 Link: http://lkml.iu.edu/hypermail/linux/kernel/1711.2/06083.html Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-27hwmon: (dell-smm) Disable fan support for Dell Inspiron 7720Pali Rohár1-1/+39
Calling fan related SMM functions implemented by Dell BIOS firmware on Dell Inspiron 7720 freeze kernel for about 500ms. Until Dell fixes it we need to disable fan support for Dell Inspiron 7720 as it makes system unusable. Via "force" module param fan support can be enabled. Reported-by: vova7890@mail.ru Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=195751 Cc: stable@vger.kernel.org # v4.0+, will need backport Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-27hwmon: (dell-smm) Enable broken functionality via "force" module paramPali Rohár1-2/+5
Some Dell machines are broken and some functionality is disabled. Show warning into dmesg about this fact and allow user via "force" module param to override brokenness and enable broken functionality. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-19hwmon: (k10temp) Add temperature offset for Ryzen 1900XGuenter Roeck1-0/+1
Like the other CPUs from the same series, the 1900X has a temperature offset of 27 degrees C. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-18hwmon: (lm75) Fix trailing semicolonLuis de Bethencourt1-1/+1
The trailing semicolon is an empty statement that does no operation. Removing it since it doesn't do anything. Signed-off-by: Luis de Bethencourt <luisbg@kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-15hwmon: (ina2xx) Fix access to uninitialized mutexMarek Szyprowski1-2/+1
Initialize data->config_lock mutex before it is used by the driver code. This fixes following warning on Odroid XU3 boards: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc7-next-20180115-00001-gb75575dee3f2 #107 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [<c0111504>] (unwind_backtrace) from [<c010dbec>] (show_stack+0x10/0x14) [<c010dbec>] (show_stack) from [<c09b3f74>] (dump_stack+0x90/0xc8) [<c09b3f74>] (dump_stack) from [<c0179528>] (register_lock_class+0x1c0/0x59c) [<c0179528>] (register_lock_class) from [<c017bd1c>] (__lock_acquire+0x78/0x1850) [<c017bd1c>] (__lock_acquire) from [<c017de30>] (lock_acquire+0xc8/0x2b8) [<c017de30>] (lock_acquire) from [<c09ca59c>] (__mutex_lock+0x60/0xa0c) [<c09ca59c>] (__mutex_lock) from [<c09cafd0>] (mutex_lock_nested+0x1c/0x24) [<c09cafd0>] (mutex_lock_nested) from [<c068b0d0>] (ina2xx_set_shunt+0x70/0xb0) [<c068b0d0>] (ina2xx_set_shunt) from [<c068b218>] (ina2xx_probe+0x88/0x1b0) [<c068b218>] (ina2xx_probe) from [<c0673d90>] (i2c_device_probe+0x1e0/0x2d0) [<c0673d90>] (i2c_device_probe) from [<c053a268>] (driver_probe_device+0x2b8/0x4a0) [<c053a268>] (driver_probe_device) from [<c053a54c>] (__driver_attach+0xfc/0x120) [<c053a54c>] (__driver_attach) from [<c05384cc>] (bus_for_each_dev+0x58/0x7c) [<c05384cc>] (bus_for_each_dev) from [<c0539590>] (bus_add_driver+0x174/0x250) [<c0539590>] (bus_add_driver) from [<c053b5e0>] (driver_register+0x78/0xf4) [<c053b5e0>] (driver_register) from [<c0675ef0>] (i2c_register_driver+0x38/0xa8) [<c0675ef0>] (i2c_register_driver) from [<c0102b40>] (do_one_initcall+0x48/0x18c) [<c0102b40>] (do_one_initcall) from [<c0e00df0>] (kernel_init_freeable+0x110/0x1d4) [<c0e00df0>] (kernel_init_freeable) from [<c09c8120>] (kernel_init+0x8/0x114) [<c09c8120>] (kernel_init) from [<c01010b4>] (ret_from_fork+0x14/0x20) Fixes: 5d389b125186 ("hwmon: (ina2xx) Make calibration register value fixed") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-15hwmon: (pmbus/ir35221) Remove unnecessary scalingSamuel Mendoza-Jonas1-189/+0
The ir35221 datasheet describes specific scaling factors for a number of commands which the current driver applies when reading. However now that the ir35221 has been tested on machines with more easily verifiable readings these descriptions have turned out to be superfluous and reading each command according to the linear format is sufficient. Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-13hwmon: (sht3x) wait predefined limits loading complete before accessEmiliano Ingrassia1-0/+7
An sht3x sensor include limits register which contains temperature and humidity limit values. After a reset, pre-defined values are loaded into that register. During the probe function, the driver reads the limits register. However, if the reads are made too early, and the bus is clocked at high frequencies (e.g. 100 kHz or more), the loading could be not completed and the sensor returns a NACK which causes the probe to fail. A delay of at least 500 us before the first read solves this issue. Signed-off-by: Emiliano Ingrassia <ingrassia@epigenesys.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-12hwmon: (pmbus/ibm-cffps) Add dependency on LEDS_CLASSArnd Bergmann1-0/+1
Building without CONFIG_LEDS_CLASS causes a link failure: drivers/hwmon/pmbus/ibm-cffps.o: In function `ibm_cffps_probe': ibm-cffps.c:(.text+0x4f4): undefined reference to `devm_of_led_classdev_register' This adds the required dependency. Fixes: ef9e1cdf419a ("hwmon: (pmbus/cffps) Add led class device ...") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-11hwmon: (pmbus/cffps) Add led class device for power supply fault ledeajames@linux.vnet.ibm.com1-8/+88
This power supply device doesn't correctly manage it's own fault led. Add an led class device and register it so that userspace can manage power supply fault led as necessary. Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-09hwmon: (pmbus) cffps: Add PMBUS_SKIP_STATUS_CHECKEddie James1-0/+6
This power supply device regularly fails to read VOUT_MODE due to the CML bit going high. This results in an incorrect exponent used for the voltage data, and therefore the power supply reports incorrect voltage. Work around this by setting the pmbus flag to skip the CML check. Signed-off-by: Eddie James <eajames@linux.vnet.ibm.com> Fixes: f69316d62c70 ("hwmon: (pmbus) Add IBM Common Form Factor (CFF) ...") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (aspeed-pwm-tacho) Deassert reset in probeJoel1-0/+22
The ASPEED SoC must deassert a reset in order to use the PWM/tach peripheral. Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (pmbus) cffps: Add debugfs entriesEdward A. James1-1/+201
Add debugfs entries for additional power supply data, including part number, serial number, FRU number, firmware revision, ccin, and the input history of the power supply. The input history is 10 minutes of input power data in the form of twenty 30-second packets. Each packet contains average and maximum power for that 30 second period. Signed-off-by: Edward A. James <eajames@us.ibm.com> [groeck: Fixed endianness problem] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (pmbus) Export pmbus device debugfs directory entryEdward A. James2-0/+10
Pmbus client drivers, if they want to use debugfs, should use the same root directory as the pmbus debugfs entries are using. Therefore, export the device dentry for the pmbus client. Signed-off-by: Edward A. James <eajames@us.ibm.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (w83773g) Fix fault detection and reportingGuenter Roeck1-1/+1
Smatch reports: drivers/hwmon/w83773g.c:105 get_fault() warn: shift has higher precedence than mask Code analysis shows that the code is indeed wrong. Fix it, and while we are at it, drop unnecessary typecast. Fixes: 86a10c802362 ("hwmon: Add W83773G driver") Cc: Lei YU <mine260309@gmail.com> Reviewed-by: Lei YU <mine260309@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (hih6130) Fix documentation of struct hih6130Guenter Roeck1-1/+1
Sparse reports: drivers/hwmon/hih6130.c:56: warning: No description found for parameter 'client' drivers/hwmon/hih6130.c:56: warning: Excess struct member 'hwmon_dev' description in 'hih6130' Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (iio_hwmon) Fix documentation of struct iio_hwmon_stateGuenter Roeck1-1/+2
Sparse reports: drivers/hwmon/iio_hwmon.c:36: warning: No description found for parameter 'groups' Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (sht15) Fix parameter documentation of sht15_crc8()Guenter Roeck1-0/+1
Sparse reports: drivers/hwmon/sht15.c:188: warning: No description found for parameter 'len' Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (sht21) Fix documentation of struct sht21Guenter Roeck1-1/+1
Sparse reports: drivers/hwmon/sht21.c:60: warning: No description found for parameter 'client' drivers/hwmon/sht21.c:60: warning: Excess struct member 'hwmon_dev' description in 'sht21' Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: Fix parameter documentationGuenter Roeck1-6/+6
sparse reports: drivers/hwmon/hwmon.c:681: warning: No description found for parameter 'chip' drivers/hwmon/hwmon.c:681: warning: Excess function parameter 'info' description in 'hwmon_device_register_with_info' drivers/hwmon/hwmon.c:789: warning: No description found for parameter 'chip' drivers/hwmon/hwmon.c:789: warning: No description found for parameter 'groups' drivers/hwmon/hwmon.c:789: warning: Excess function parameter 'info' description in 'devm_hwmon_device_register_with_info' Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (max31785) Add OF device ID tableJavier Martinez Canillas1-0/+9
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Before this patch: $ modinfo drivers/hwmon/pmbus/max31785.ko | grep alias alias: i2c:max31785a alias: i2c:max31785 After this patch: $ modinfo drivers/hwmon/pmbus/max31785.ko | grep alias alias: i2c:max31785a alias: i2c:max31785 alias: of:N*T*Cmaxim,max31785aC* alias: of:N*T*Cmaxim,max31785a alias: of:N*T*Cmaxim,max31785C* alias: of:N*T*Cmaxim,max31785 Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (ina2xx) Make calibration register value fixedMaciej Purski1-37/+50
Calibration register is used for calculating current register in hardware according to datasheet: current = shunt_volt * calib_register / 2048 (ina 226) current = shunt_volt * calib_register / 4096 (ina 219) Fix calib_register value to 2048 for ina226 and 4096 for ina 219 in order to avoid truncation error and provide best precision allowed by shunt_voltage measurement. Make current scale value follow changes of shunt_resistor from sysfs as calib_register value is now fixed. Power_lsb value should also follow shunt_resistor changes as stated in datasheet: power_lsb = 25 * current_lsb (ina 226) power_lsb = 20 * current_lsb (ina 219) Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (pmbus/max31785) Add dual tachometer supportAndrew Jeffery1-0/+147
The dual tachometer feature is implemented in hardware with a TACHSEL input to indicate the rotor under measurement, and exposed on the device by extending the READ_FAN_SPEED_1 word with two extra bytes*. The need to read the non-standard four-byte response leads to a cut-down implementation of i2c_smbus_xfer_emulated() included in the driver. Further, to expose the second rotor tachometer value to userspace the values are exposed through virtual pages. We re-route accesses to FAN_CONFIG_1_2 and READ_FAN_SPEED_1 on pages 23-28 (not defined by the hardware) to the same registers on pages 0-5, and with the latter command we extract the value from the second word of the four-byte response. * The documentation recommends the slower rotor be associated with TACHSEL=0, which corresponds to the first word of the response. The TACHSEL=0 measurement is used by the controller's closed-loop fan management to judge target fan rate. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (pmbus) Add virtual page config bitAndrew Jeffery2-9/+20
Some circumstances call for virtual pages, to expose multiple values packed into an extended PMBus register in a manner non-compliant with the PMBus standard. An example of this is the Maxim MAX31785 controller, which extends the READ_FAN_SPEED_1 PMBus register from two to four bytes to support tach readings for both rotors of a dual rotor fan. This extended register contains two word-sized values, one reporting the rate of the fastest rotor, the other the rate of the slowest. The concept of virtual pages aids this situation by mapping the page number onto the value to be selected from the vectored result. We should not try to set virtual pages on the device as such a page explicitly doesn't exist; add a flag so we can avoid doing so. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (pmbus/max31785) Add fan controlAndrew Jeffery1-1/+137
The implementation makes use of the new fan control virtual registers exposed by the pmbus core. It mixes use of the default implementations with some overrides via the read/write handlers to handle FAN_COMMAND_1 on the MAX31785, whose definition breaks the value range into various control bands dependent on RPM or PWM mode. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-03hwmon: (pmbus) Add fan control supportAndrew Jeffery2-18/+259
Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes. Fans in a PMBus device are driven by the configuration of two registers, FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan and the tacho operate (if installed), while FAN_COMMAND_x sets the desired fan rate. The unit of FAN_COMMAND_x is dependent on the operational fan mode, RPM or PWM percent duty, as determined by the corresponding configuration in FAN_CONFIG_x_y. The mapping of fanX_target, pwmX and pwmX_enable onto FAN_CONFIG_x_y and FAN_COMMAND_x is implemented with the addition of virtual registers to facilitate the necessary side-effects of each access: 1. PMBUS_VIRT_FAN_TARGET_x 2. PMBUS_VIRT_PWM_x 3. PMBUS_VIRT_PWM_ENABLE_x Some complexity arises with the fanX_target and pwmX attributes both mapping onto FAN_COMMAND_x: There is no general mapping between PWM percent duty and RPM, so we can't display values in either attribute in terms of the other (which in my mind is the intuitive, if impossible, behaviour). This problem also affects the pwmX_enable attribute which allows userspace to switch between full speed, manual PWM and a number of automatic control modes, possibly including a switch to RPM behaviour (e.g. automatically adjusting PWM duty to reach a RPM target, the behaviour of fanX_target). The next most intuitive behaviour is for fanX_target and pwmX to simply be independent, to retain their most recently set value even if that value is not active on the hardware (due to switching to the alternative control mode). This property of retaining the value independent of the hardware state has useful results for both userspace and the kernel: Userspace always sees a sensible value in the attribute (the last thing it was set to, as opposed to 0 or receiving an error on read), and the kernel can use the attributes as a value cache. This latter point eases the implementation of pwmX_enable, which can look up the associated pmbus_sensor object, take its cached value and apply it to hardware on changing control mode. This ensures we will not arbitrarily set a PWM value as an RPM value or vice versa, and we can assume that the RPM or PWM value set was sensible at least at some point in the past. Finally, the DIRECT mode coefficients of some controllers is different between RPM and PWM percent duty control modes, so PSC_PWM is introduced to capture the necessary coefficients. As pmbus core had no PWM support previously PSC_FAN continues to be used to capture the RPM DIRECT coefficients, but in order to avoid falsely applying RPM scaling to PWM values I have introduced the PMBUS_HAVE_PWM12 and PMB_BUS_HAVE_PWM34 feature bits. These feature bits allow drivers to explicitly declare PWM support in order to have the attributes exposed. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Guenter Roeck <linux@roeck-us.net>