summaryrefslogtreecommitdiff
path: root/drivers/hwmon/pmbus
AgeCommit message (Collapse)AuthorFilesLines
2018-05-17hwmon: (pmbus) Use 64bit math for DIRECT format valuesRobert Lippert1-9/+12
Power values in the 100s of watt range can easily blow past 32bit math limits when processing everything in microwatts. Use 64bit math instead to avoid these issues on common 32bit ARM BMC platforms. Fixes: 442aba78728e ("hwmon: PMBus device driver") Signed-off-by: Robert Lippert <rlippert@google.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> (cherry picked from commit bd467e4eababe4c04272c1e646f066db02734c79) Signed-off-by: Joel Stanley <joel@jms.id.au>
2018-04-04pmbus (max31785): Wrap all I2C accessors in one-shot failure handlersAndrew Jeffery1-42/+165
The MAX31785(A) has shown erratic behaviour across multiple system designs, unexpectedly clock stretching and NAKing transactions. Perform a one-shot retry if necessary for all access attempts. OpenBMC-Staging-Count: 2 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Tested-by: George Keishing <gkeishin@in.ibm.com>
2018-04-04pmbus (core): Use driver callbacks in pmbus_get_fan_rate()Andrew Jeffery1-4/+4
The driver may have overridden the pmbus_read_byte_data() callback, so make sure we use that to achieve expected behaviour. This helps in the MAX31785 case where we may need to perform a one-shot retry of transfers in the face of a failure. OpenBMC-Staging-Count: 2 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Eddie James <eajames@linux.vnet.ibm.com> Tested-by: George Keishing <gkeishin@in.ibm.com>
2018-04-04pmbus (core): One-shot retries for failure to set pageAndrew Jeffery1-2/+10
Work around the shonky behaviour seen with the MAX31785 where we fail to set the page register in some circumstances. There's no real elegant way to do this. We can propagate the error up, but that forces us to retry the operation way up the call tree in any number of places. It also forces callers to split out pmbus_set_page() from the pmbus_{read,write}_{byte,word}_data() functions in order to differentiate between a failure to set the page and a failure to read a register (that might not exist, in which case an error is anticiptated). OpenBMC-Staging-Count: 2 Cc: Eddie James <eajames@linux.vnet.ibm.com> Cc: Matt Spinler <mspinler@linux.vnet.ibm.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Eddie James <eajames@linux.vnet.ibm.com> Tested-by: George Keishing <gkeishin@in.ibm.com>
2018-04-04pmbus (max31785): Add support for devicetree configurationAndrew Jeffery1-0/+318
OpenBMC-Staging-Count: 2 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Tested-by: George Keishing <gkeishin@in.ibm.com>
2018-03-19hwmon: (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> (cherry picked from commit 72816cb06e7153c22aed8776949f558b635aa2c0) Signed-off-by: Joel Stanley <joel@jms.id.au>
2018-03-19hwmon: (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> (cherry picked from commit ca781fb7fd95ba90eda6936a27fc1e3202f99d6a) Signed-off-by: Joel Stanley <joel@jms.id.au>
2018-03-07hwmon: (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> (cherry picked from commit 08f411bcb5fbd96c53d4535e0526f70b971ee5d5) Signed-off-by: Joel Stanley <joel@jms.id.au>
2018-03-07hwmon: (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> (cherry picked from commit ef9e1cdf419a37065364edb47bd6dd9aee1bcb7d) Signed-off-by: Joel Stanley <joel@jms.id.au>
2018-03-07hwmon: (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> (cherry picked from commit 4471879acf926221231fe68ebc30f9cad0d7f7c8) Signed-off-by: Joel Stanley <joel@jms.id.au>
2018-03-07hwmon: (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> (cherry picked from commit d6bb645a1704cba3884bf03d5a8bd86915b5e650) Signed-off-by: Joel Stanley <joel@jms.id.au>
2018-03-07hwmon: (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> (cherry picked from commit eb6489b696ad22a8464e20502e18014434b4b0ea) Signed-off-by: Joel Stanley <joel@jms.id.au>
2017-11-28pmbus (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: Joel Stanley <joel@jms.id.au>
2017-11-28pmbus (core): 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: Joel Stanley <joel@jms.id.au>
2017-11-28pmbus (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: Joel Stanley <joel@jms.id.au>
2017-11-28pmbus (core): 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: Joel Stanley <joel@jms.id.au>
2017-11-28pmbus: Add driver for Maxim MAX31785 Intelligent Fan ControllerAndrew Jeffery3-0/+127
The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan management with temperature and remote voltage sensing. It supports various fan control features, including PWM frequency control, temperature hysteresis, dual tachometer measurements, and fan health monitoring. This patch presents a basic driver using only the existing features of the PMBus subsystem. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> [groeck: Modified description to clarify that fan control is not yet provided] Signed-off-by: Guenter Roeck <linux@roeck-us.net> (cherry picked from commit 4d420a6a9ddd72bd25baa6e667dd0581506eeacb) Signed-off-by: Joel Stanley <joel@jms.id.au>
2017-11-28hwmon: (pmbus/core) Prevent unintentional setting of page to 0xFFEdward A. James2-17/+14
The pmbus core may call read/write word data functions with a page value of -1, intending to perform the operation without setting the page. However, the read/write word data functions accept only unsigned 8-bit page numbers, and therefore cannot check for negative page number to avoid setting the page. This results in setting the page number to 0xFF. This may result in errors or undefined behavior of some devices (specifically the ir35221, which allows the page to be set to 0xFF, but some subsequent operations to read registers may fail). Switch the pmbus_set_page page parameter to an integer and perform the check for negative page there. Make read/write functions consistent in accepting an integer page number parameter. Signed-off-by: Edward A. James <eajames@us.ibm.com> Fixes: cbcdec6202c9 ("hwmon: (pmbus): Access word data for STATUS_WORD") Signed-off-by: Guenter Roeck <linux@roeck-us.net> (cherry picked from commit 6dcf2fb5e8db3704f50af1f198256cb4e2453f8b) Signed-off-by: Joel Stanley <joel@jms.id.au>
2017-11-28hwmon: (pmbus) Add IBM Common Form Factor (CFF) power supply driverEdward A. James3-0/+161
Add the driver to monitor IBM CFF power supplies with hwmon over pmbus. Signed-off-by: Edward A. James <eajames@us.ibm.com> [groeck: drop 'default n'; include bitops.h instead of jiffies.h] Signed-off-by: Guenter Roeck <linux@roeck-us.net> (cherry picked from commit f69316d62c7066edc4693b85c6e9f987eed62772) Signed-off-by: Joel Stanley <joel@jms.id.au>
2017-11-28hwmon: (pmbus) Add debugfs for status registersEdward A. James1-0/+210
Export all the available status registers through debugfs. This is useful for hardware diagnostics, especially on multi-page pmbus devices, as user-space access of the i2c space could corrupt the pmbus page accounting. Signed-off-by: Edward A. James <eajames@us.ibm.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> (cherry picked from commit 1e069dfd96dfeacf1d781f6eaea9426aed0b0909) Signed-off-by: Joel Stanley <joel@jms.id.au>
2017-11-28hwmon: (pmbus): Add generic alarm bit for iin and pinEdward A. James1-1/+9
Add PB_STATUS_INPUT as the generic alarm bit for iin and pin. We also need to redo the status register checking before setting up the boolean attribute, since it won't necessarily check STATUS_WORD if the device doesn't support it, which we need for this bit. Signed-off-by: Edward A. James <eajames@us.ibm.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> (cherry picked from commit c159be9e902a59a117e67d466c872ecc46240ba5) Signed-off-by: Joel Stanley <joel@jms.id.au>
2017-11-28hwmon: (pmbus): Access word data for STATUS_WORDEdward A. James1-14/+40
Pmbus always reads byte data from the status register, even if configured to use STATUS_WORD. Use a function pointer to read the correct amount of data from the registers. Also switch to try STATUS_WORD first before STATUS_BYTE on init. Signed-off-by: Edward A. James <eajames@us.ibm.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> (cherry picked from commit cbcdec6202c934bd72fca4fe9db255d84f907dbe) Signed-off-by: Joel Stanley <joel@jms.id.au>
2017-11-28hwmon: (pmbus): Switch status registers to 16 bitEdward A. James1-7/+7
Switch the storage of status registers to 16 bit values. This allows us to store all the bits of STATUS_WORD. Signed-off-by: Edward A. James <eajames@us.ibm.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> (cherry picked from commit a66a6eb9db10bd630bacf31e33505302c8e8303c) Signed-off-by: Joel Stanley <joel@jms.id.au>
2017-06-12hwmon: (pmbus) move header file out of I2C realmWolfram Sang4-4/+4
include/linux/i2c is not for client devices. Move the header file to a more appropriate location. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-06-12hwmon: (pmbus) Add client driver for IR35221Samuel Mendoza-Jonas3-0/+348
IR35221 is a Digital DC-DC Multiphase Converter Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com> [groeck: Preserve alphabetic order in Kconfig; add missing break statements (from Dan Carpenter); add missing error checks] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02hwmon: (ucd9200) Add OF device ID tableJavier Martinez Canillas1-1/+47
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. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-04-02hwmon: (ucd9000) Add OF device ID tableJavier Martinez Canillas1-1/+38
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. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-03-28driver: (adm1275) set the m,b and R coefficients correctly for powerShikhar Dogra1-2/+2
Seems like coefficient values for m, b and R under power have been put in the wrong order. Rearranging them properly to get correct values of coefficients for power. For specs, please refer to table 7 (page 35) on http://www.analog.com/media/en/technical-documentation/data-sheets/ADM1075.pdf Fixes: 904b296f308d ("hwmon: (adm1275) Introduce configuration data structure for coeffcients") Signed-off-by: Shikhar Dogra <shidogra@cisco.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2016-12-03hwmon: (adm1275) Enable adm1278 VOUT samplingYi Li1-4/+16
The adm1278 can optionally monitor the VOUT pin. This functionality is not enabled at reset, so PMON_CONFIG needs to be modified in order to enable it. Signed-off-by: Yi Li <adamliyi@msn.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2016-09-09hwmon: (ucd9000) Add support for UCD90160 Power Supply SequencerMatt Weber2-4/+5
The UCD90160 Power Supply Sequencer reuses the existing register layout, so just an id addition was required. Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com> Signed-off-by: Ronak Desai <ronak.desai@rockwellcollins.com> [groeck: Updated description, ordered alphabetically, added documentation] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2016-09-09hwmon: (pmbus) Add explicit support for DPS-460, DPS-800, and SGD009Vadim Pasternak1-2/+18
Provide support for PSU DPS-460, DPS-800 from Delta Electronics, INC and for SGD009 from Acbel Polytech, INC. These devices do not support the STATUS_CML register, and reports a communication error in response to this command. For this reason, the status register check is disabled for these controllers. Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2016-03-05hwmon: (adm1275) Add support for ADM1278Guenter Roeck2-3/+57
ADM1278 is mostly compatible to other chips of the same series. Besides the usual difference in coefficients, it supports a temperature sensor, and it can measure both input and output voltage at the same time. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-12-18hwmon: (pmbus) Add client driver for LTC3815Guenter Roeck3-0/+226
LTC3815 is a Monolithic Synchronous DC/DC Step-Down Converter. Cc: Michael Jones <mike@proclivis.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-19hwmon: (ltc2978) Add support for LTM4675Guenter Roeck2-3/+9
LTM2975 is a dual 9A or single 18A μModule regulator. It is register compatible with LTM4676. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-19hwmon: (ltc2978) Add polling for chips requiring itMichael Jones1-10/+101
Some of the LTC chips supported by this driver have to be polled to ensure that they are ready to accept commands. Signed-off-by: Michael Jones <mike@proclivis.com> [Guenter Roeck: simplifications and formatting changes] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-19hwmon: (pmbus) Enable PEC if the controller supports itGuenter Roeck1-0/+5
PMBus controllers optionally support PEC. Configure the driver to use it if available to improve operational security. Suggested-by: Michael Jones <mike@proclivis.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-19hwmon: (pmbus) Use BIT macroGuenter Roeck5-102/+107
Using the BIT macro makes the code a little easier to read. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-18hwmon: (ltc2978) Add support for LTC3886Guenter Roeck2-3/+23
LTC3886 is a is a dual PolyPhase DC/DC synchronous step-down switching regulator controller. It is mostly command compatible to LTC3883, but supports two phases instead of one. Suggested-by: Michael Jones <mike@proclivis.com> Tested-by: Michael Jones <mike@proclivis.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-18hwmon: (ltc2978) Add support for LTC2980 and LTM2987Guenter Roeck2-5/+19
LTC2980 and LTM2987 are command compatible to LTC2977. They consist of two LTC2977 on a single die, and are instantiated as two separate chips, each supporting eight channels. Suggested-by: Michael Jones <mike@proclivis.com> Tested-by: Michael Jones <mike@proclivis.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-18hwmon: (ltc2978) Add missing chip IDs for LTC2978 and LTC3882Guenter Roeck1-3/+8
Add additional chip ID for an older revision of LTC2978, as well as two chip IDs for LTC3882. Turns out the LTC3882 does support the LTC2978_MFR_SPECIAL_ID register, and reading it returns its chip ID, but the register is undocumented. Suggested-by: Michael Jones <mike@proclivis.com> Tested-by: Michael Jones <mike@proclivis.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-18hwmon: (ltc2978) Use correct ID mask to detect all chipsGuenter Roeck1-22/+17
Per information from Linear Technologies, the ID mask is 12 bit for all chips of this series. Use this mask to detect chips to ensure that all chip revisions are detected. Suggested-by: Michael Jones <mike@proclivis.com> Tested-by: Michael Jones <mike@proclivis.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-17hwmon: (ltc2978) Introduce helper functions for min and max valuesGuenter Roeck1-91/+57
The code used to determine historic low and high peaks is repeated several times. Introduce helper functions to simplify it. Tested-by: Michael Jones <mike@proclivis.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-17hwmon: (ltc2978) Introduce feature flagsGuenter Roeck1-12/+18
It is becoming cumbersom to track per-chip feature support. Introduce feature flag to simplify the code. Tested-by: Michael Jones <mike@proclivis.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-17hwmon: (pmbus) Convert command register definitions to enumGuenter Roeck1-140/+142
This will simplify adding new virtual commands. Tested-by: Michael Jones <mike@proclivis.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-17hwmon: (ltc2978) Add support for LTC2975Guenter Roeck2-12/+96
LTC2975 is mostly compatible to LTC2974, but supports input current and power measurement. Tested-by: Michael Jones <mike@proclivis.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-12hwmon: (ltc2978) Add support for LTC3887Guenter Roeck2-6/+16
LTC3887 is an enhanced version of LTC3880 and supports the same commands. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-12hwmon: (ltc2978) Add additional chip IDs for LTM4676 and LTM4676AGuenter Roeck1-2/+6
Per datasheet, the chip ID for LTM4676 is 0x448x. This was observed in real systems. In addition to that, chip ID 0x4401 was observed as well. Research shows that the chip ID has been changed from 0x440x to 0x448x in datasheet revision C. Add support for the additional chip ID. Also add the chip ID for LTM4676A, which is functionally identical to LTM4676. Reported-by: Ananda Babu Nettam <anandab@juniper.net> Cc: Ananda Babu Nettam <anandab@juniper.net> Cc: Amit U Jain <amjain@juniper.net> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-12hwmon: (ltc2978) Add support for LTC3882Guenter Roeck1-6/+44
LTC3882 is mostly compatible with LTC3880. Major differences are that it does not measure the input current, and it no longer supports LTC's legacy mechanism to identify the chip. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-12hwmon: (ltc2978) Move code to read chip ID into separate functionGuenter Roeck1-19/+29
Verifying the chip type is getting more complicated with new chips, since not all chips support the same mechanism to read the chip type. Move the code into a separate function to simplify adding support for those chips. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-11hwmon: (pmbus) Add device IDs for TPS544{B,C}2{0,5}Guenter Roeck2-1/+6
Add device IDs and references for Texas Instruments TPS544B20, TPS544B25, TPS544C20, and TPS544C25 to the generic PMBus driver. Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>