summaryrefslogtreecommitdiff
path: root/drivers/hwmon/pmbus
AgeCommit message (Collapse)Author
2018-07-08hwmon: (pmbus/max34440) Add support for MAX34451.Kun Yi
MAX34451 is a 16-Channel Voltage/Current Monitor and 12-Channel Sequencer. Signed-off-by: Kun Yi <kunyi@google.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-06-12treewide: devm_kzalloc() -> devm_kcalloc()Kees Cook
The devm_kzalloc() function has a 2-factor argument form, devm_kcalloc(). This patch replaces cases of: devm_kzalloc(handle, a * b, gfp) with: devm_kcalloc(handle, a * b, gfp) as well as handling cases of: devm_kzalloc(handle, a * b * c, gfp) with: devm_kzalloc(handle, array3_size(a, b, c), gfp) as it's slightly less ugly than: devm_kcalloc(handle, array_size(a, b), c, gfp) This does, however, attempt to ignore constant size factors like: devm_kzalloc(handle, 4 * 1024, gfp) though any constants defined via macros get caught up in the conversion. Any factors with a sizeof() of "unsigned char", "char", and "u8" were dropped, since they're redundant. Some manual whitespace fixes were needed in this patch, as Coccinelle really liked to write "=devm_kcalloc..." instead of "= devm_kcalloc...". The Coccinelle script used for this was: // Fix redundant parens around sizeof(). @@ expression HANDLE; type TYPE; expression THING, E; @@ ( devm_kzalloc(HANDLE, - (sizeof(TYPE)) * E + sizeof(TYPE) * E , ...) | devm_kzalloc(HANDLE, - (sizeof(THING)) * E + sizeof(THING) * E , ...) ) // Drop single-byte sizes and redundant parens. @@ expression HANDLE; expression COUNT; typedef u8; typedef __u8; @@ ( devm_kzalloc(HANDLE, - sizeof(u8) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(__u8) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(char) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(unsigned char) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(u8) * COUNT + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(__u8) * COUNT + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(char) * COUNT + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(unsigned char) * COUNT + COUNT , ...) ) // 2-factor product with sizeof(type/expression) and identifier or constant. @@ expression HANDLE; type TYPE; expression THING; identifier COUNT_ID; constant COUNT_CONST; @@ ( - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * (COUNT_ID) + COUNT_ID, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * COUNT_ID + COUNT_ID, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * (COUNT_CONST) + COUNT_CONST, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * COUNT_CONST + COUNT_CONST, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * (COUNT_ID) + COUNT_ID, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * COUNT_ID + COUNT_ID, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * (COUNT_CONST) + COUNT_CONST, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * COUNT_CONST + COUNT_CONST, sizeof(THING) , ...) ) // 2-factor product, only identifiers. @@ expression HANDLE; identifier SIZE, COUNT; @@ - devm_kzalloc + devm_kcalloc (HANDLE, - SIZE * COUNT + COUNT, SIZE , ...) // 3-factor product with 1 sizeof(type) or sizeof(expression), with // redundant parens removed. @@ expression HANDLE; expression THING; identifier STRIDE, COUNT; type TYPE; @@ ( devm_kzalloc(HANDLE, - sizeof(TYPE) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) ) // 3-factor product with 2 sizeof(variable), with redundant parens removed. @@ expression HANDLE; expression THING1, THING2; identifier COUNT; type TYPE1, TYPE2; @@ ( devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(TYPE2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) ) // 3-factor product, only identifiers, with redundant parens removed. @@ expression HANDLE; identifier STRIDE, SIZE, COUNT; @@ ( devm_kzalloc(HANDLE, - (COUNT) * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - (COUNT) * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - (COUNT) * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - (COUNT) * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) ) // Any remaining multi-factor products, first at least 3-factor products, // when they're not all constants... @@ expression HANDLE; expression E1, E2, E3; constant C1, C2, C3; @@ ( devm_kzalloc(HANDLE, C1 * C2 * C3, ...) | devm_kzalloc(HANDLE, - (E1) * E2 * E3 + array3_size(E1, E2, E3) , ...) | devm_kzalloc(HANDLE, - (E1) * (E2) * E3 + array3_size(E1, E2, E3) , ...) | devm_kzalloc(HANDLE, - (E1) * (E2) * (E3) + array3_size(E1, E2, E3) , ...) | devm_kzalloc(HANDLE, - E1 * E2 * E3 + array3_size(E1, E2, E3) , ...) ) // And then all remaining 2 factors products when they're not all constants, // keeping sizeof() as the second factor argument. @@ expression HANDLE; expression THING, E1, E2; type TYPE; constant C1, C2, C3; @@ ( devm_kzalloc(HANDLE, sizeof(THING) * C2, ...) | devm_kzalloc(HANDLE, sizeof(TYPE) * C2, ...) | devm_kzalloc(HANDLE, C1 * C2 * C3, ...) | devm_kzalloc(HANDLE, C1 * C2, ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * (E2) + E2, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * E2 + E2, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * (E2) + E2, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * E2 + E2, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - (E1) * E2 + E1, E2 , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - (E1) * (E2) + E1, E2 , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - E1 * E2 + E1, E2 , ...) ) Signed-off-by: Kees Cook <keescook@chromium.org>
2018-03-22hwmon: (pmbus/adm1275) Add support for ADM1272Guenter Roeck
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-16hwmon: (ucd9000) Add debugfs attributes to provide mfr_statusChristopher Bostic
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-16hwmon: (ucd9000) Add gpio chip interfaceChristopher Bostic
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-10hwmon: (pmbus/adm1275) Accept negative page register valuesGuenter Roeck
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-10hwmon: (pmbus/max8688) Accept negative page register valuesGuenter Roeck
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-01-15hwmon: (pmbus/ir35221) Remove unnecessary scalingSamuel Mendoza-Jonas
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-12hwmon: (pmbus/ibm-cffps) Add dependency on LEDS_CLASSArnd Bergmann
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.com
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-08hwmon: (pmbus) cffps: Add PMBUS_SKIP_STATUS_CHECKEddie James
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-02hwmon: (pmbus) cffps: Add debugfs entriesEdward A. James
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-02hwmon: (pmbus) Export pmbus device debugfs directory entryEdward A. James
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-02hwmon: (max31785) Add OF device ID tableJavier Martinez Canillas
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-02hwmon: (pmbus/max31785) Add dual tachometer supportAndrew Jeffery
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-02hwmon: (pmbus) Add virtual page config bitAndrew Jeffery
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-02hwmon: (pmbus/max31785) Add fan controlAndrew Jeffery
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-02hwmon: (pmbus) Add fan control supportAndrew Jeffery
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>
2018-01-02hwmon: (pmbus/lm25066) Drop support for LM25063Guenter Roeck
LM25063 was never released. Drop support for it. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-11-27hwmon: (pmbus) Use 64bit math for DIRECT format valuesRobert Lippert
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>
2017-11-13Merge tag 'hwmon-for-linus-v4.15' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon updates from Guenter Roeck: - drivers for MAX31785 and MAX6621 - support for AMD family 17h (Ryzen, Threadripper) temperature sensors - various driver cleanups and minor improvements * tag 'hwmon-for-linus-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (30 commits) dt-bindings: pmbus: Add Maxim MAX31785 documentation pmbus: Add driver for Maxim MAX31785 Intelligent Fan Controller hwmon: (aspeed-pwm-tacho) Sort headers hwmon: (xgene) Minor clean up of ifdef and acpi_match_table reference hwmon: (max6621) Inverted if condition in max6621_read() hwmon: (asc7621) remove redundant assignment to newval hwmon: (xgene) Support hwmon v2 hwmon: (gpio-fan) Fix null pointer dereference at probe hwmon: (gpio-fan) Convert to use GPIO descriptors hwmon: (gpio-fan) Rename GPIO line state variables hwmon: (gpio-fan) Get rid of the gpio alarm struct hwmon: (gpio-fan) Get rid of platform data struct hwmon: (gpio-fan) Mandate OF_GPIO and cut pdata path hwmon: (gpio-fan) Send around device pointer hwmon: (gpio-fan) Localize platform data hwmon: (gpio-fan) Use local variable pointers hwmon: (gpio-fan) Move DT bindings to the right place Documentation: devicetree: add max6621 device hwmon: (max6621) Add support for Maxim MAX6621 temperature sensor hwmon: (w83793) make const array watchdog_minors static, reduces object code size ...
2017-11-05pmbus: Add driver for Maxim MAX31785 Intelligent Fan ControllerAndrew Jeffery
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>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-29hwmon: (pmbus/core) Prevent unintentional setting of page to 0xFFEdward A. James
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>
2017-08-30hwmon: (pmbus) Add support for Texas Instruments tps53679 deviceVadim Pasternak
The below lists of VOUT_MODE command readout with their related VID protocols, Digital to Analog Converter steps, supported by the device: VR12.0 mode, 5-mV DAC - 0x21 VR12.5 mode, 10-mV DAC - 0x22 VR13.0 mode, 10-mV DAC - 0x24 IMVP8 mode, 5-mV DAC - 0x25 VR13.0 mode, 5-mV DAC - 0x27 Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-08-30hwmon: (pmbus/lm25066) Add support for TI LM5066IXo Wang
The TI LM5066I hotswap controller is a more accurate version of the LM5066 device already supported. It has different measurement conversion coefficients than the LM5066, so it needs to be recognized as a different device. Signed-off-by: Xo Wang <xow@google.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-08-30hwmon: (pmbus/lm25066) Offset coefficient depends on CLXo Wang
When converting the DIRECT format CURRENT_IN and POWER commands, make the offset coefficient ("b") predicate on the value of the current limit setting. Signed-off-by: Xo Wang <xow@google.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-08-30hwmon: (pmbus) Add support for Intel VID protocol VR13Vadim Pasternak
The below lists of VOUT_MODE command readout with their related VID protocols, Digital to Analog Converter steps: - VR13.0 mode, 10-mV DAC - 0x24 - VR13.0 mode, 5-mV DAC - 0x27 Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2017-08-29hwmon: (pmbus) Add IBM Common Form Factor (CFF) power supply driverEdward A. James
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>
2017-08-14hwmon: (pmbus) Add debugfs for status registersEdward A. James
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>
2017-08-13hwmon: (pmbus): Add generic alarm bit for iin and pinEdward A. James
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>
2017-08-13hwmon: (pmbus): Access word data for STATUS_WORDEdward A. James
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>
2017-08-13hwmon: (pmbus): Switch status registers to 16 bitEdward A. James
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>
2017-06-11hwmon: (pmbus) move header file out of I2C realmWolfram Sang
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-11hwmon: (pmbus) Add client driver for IR35221Samuel Mendoza-Jonas
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 Canillas
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 Canillas
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-27driver: (adm1275) set the m,b and R coefficients correctly for powerShikhar Dogra
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-02hwmon: (adm1275) Enable adm1278 VOUT samplingYi Li
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-08hwmon: (ucd9000) Add support for UCD90160 Power Supply SequencerMatt Weber
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-08hwmon: (pmbus) Add explicit support for DPS-460, DPS-800, and SGD009Vadim Pasternak
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 Roeck
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 Roeck
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 Roeck
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 Jones
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 Roeck
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 Roeck
Using the BIT macro makes the code a little easier to read. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-08-17hwmon: (ltc2978) Add support for LTC3886Guenter Roeck
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-17hwmon: (ltc2978) Add support for LTC2980 and LTM2987Guenter Roeck
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-17hwmon: (ltc2978) Add missing chip IDs for LTC2978 and LTC3882Guenter Roeck
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>
generated by cgit (git 2.34.1) at 2024-06-20 13:20:56 +0000