summaryrefslogtreecommitdiff
path: root/drivers/hwmon
AgeCommit message (Collapse)AuthorFilesLines
2020-07-03hwmon: (pmbus) fix a typo in Kconfig SENSORS_IR35221 optionTao Ren1-1/+1
Fix a typo in SENSORS_IR35221 option: module name should be "ir35221" instead of "ir35521". Fixes: 8991ebd9c9a6 ("hwmon: (pmbus) Add client driver for IR35221") Cc: Samuel Mendoza-Jonas <sam@mendozajonas.com> Signed-off-by: Tao Ren <rentao.bupt@gmail.com> Link: https://lore.kernel.org/r/20200702221349.18139-1-rentao.bupt@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-06-26hwmon: (acpi_power_meter) Fix potential memory leak in acpi_power_meter_add()Misono Tomohiro1-1/+3
Although it rarely happens, we should call free_capabilities() if error happens after read_capabilities() to free allocated strings. Fixes: de584afa5e188 ("hwmon driver for ACPI 4.0 power meters") Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com> Link: https://lore.kernel.org/r/20200625043242.31175-1-misono.tomohiro@jp.fujitsu.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-06-24hwmon: (max6697) Make sure the OVERT mask is set correctlyChu Lin1-3/+4
Per the datasheet for max6697, OVERT mask and ALERT mask are different. For example, the 7th bit of OVERT is the local channel but for alert mask, the 6th bit is the local channel. Therefore, we can't apply the same mask for both registers. In addition to that, the max6697 driver is supposed to be compatibale with different models. I manually went over all the listed chips and made sure all chip types have the same layout. Testing; mask value of 0x9 should map to 0x44 for ALERT and 0x84 for OVERT. I used iotool to read the reg value back to verify. I only tested this change on max6581. Reference: https://datasheets.maximintegrated.com/en/ds/MAX6581.pdf https://datasheets.maximintegrated.com/en/ds/MAX6697.pdf https://datasheets.maximintegrated.com/en/ds/MAX6699.pdf Signed-off-by: Chu Lin <linchuyuan@google.com> Fixes: 5372d2d71c46e ("hwmon: Driver for Maxim MAX6697 and compatibles") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-06-23hwmon: (pmbus) Fix page vs. register when accessing fansJan Kundrát1-4/+4
Commit 16358542f32f ("hwmon: (pmbus) Implement multi-phase support") added support for multi-phase pmbus devices. However, when calling pmbus_add_sensor() for fans, the patch swapped the `page` and `reg` attributes. As a result, the fan speeds were reported as 0 RPM on my device. Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Fixes: 16358542f32f ("hwmon: (pmbus) Implement multi-phase support") Cc: stable@vger.kernel.org # v5.7+ Link: https://lore.kernel.org/r/449bc9e6c0e4305581e45905ce9d043b356a9932.1592904387.git.jan.kundrat@cesnet.cz [groeck: Fixed references to offending commit] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-06-23hwmon: (bt1-pvt) Mark is_visible functions staticGuenter Roeck1-4/+4
0-day reports: drivers/hwmon/bt1-pvt.c:303:16: warning: no previous declaration for 'pvt_limit_is_visible' drivers/hwmon/bt1-pvt.c:308:16: warning: no previous declaration for 'pvt_alarm_is_visible' Declare both functions static. Reported-by: kernel test robot <lkp@intel.com> Fixes: 87976ce2825d("hwmon: Add Baikal-T1 PVT sensor driver") Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-06-23hwmon: (bt1-pvt) Define Temp- and Volt-to-N poly as maybe-unusedSerge Semin1-2/+2
Clang-based kernel building with W=1 warns that some static const variables are unused: drivers/hwmon/bt1-pvt.c:67:30: warning: unused variable 'poly_temp_to_N' [-Wunused-const-variable] static const struct pvt_poly poly_temp_to_N = { ^ drivers/hwmon/bt1-pvt.c:99:30: warning: unused variable 'poly_volt_to_N' [-Wunused-const-variable] static const struct pvt_poly poly_volt_to_N = { ^ Indeed these polynomials are utilized only when the PVT sensor alarms are enabled. In that case they are used to convert the temperature and voltage alarm limits from normal quantities (Volts and degree Celsius) to the sensor data representation N = [0, 1023]. Otherwise when alarms are disabled the driver only does the detected data conversion to the human readable form and doesn't need that polynomials defined. So let's mark the Temp-to-N and Volt-to-N polynomials with __maybe_unused attribute. Note gcc with W=1 doesn't notice the problem. Fixes: 87976ce2825d ("hwmon: Add Baikal-T1 PVT sensor driver") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200603000753.391-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-06-11Merge branch 'x86/entry' into ras/coreThomas Gleixner27-120/+3233
to fixup conflicts in arch/x86/kernel/cpu/mce/core.c so MCE specific follow up patches can be applied without creating a horrible merge conflict afterwards.
2020-05-28hwmon: Add Baikal-T1 PVT sensor driverSerge Semin4-0/+1416
Baikal-T1 SoC provides an embedded process, voltage and temperature sensor to monitor an internal SoC environment (chip temperature, supply voltage and process monitor) and on time detect critical situations, which may cause the system instability and even damages. The IP-block is based on the Analog Bits PVT sensor, but is equipped with a dedicated control wrapper, which provides a MMIO registers-based access to the sensor core functionality (APB3-bus based) and exposes an additional functions like thresholds/data ready interrupts, its status and masks, measurements timeout. All of these is used to create a hwmon driver being added to the kernel by this commit. The driver implements support for the hardware monitoring capabilities of Baikal-T1 process, voltage and temperature sensors. PVT IP-core consists of one temperature and four voltage sensors, each of which is implemented as a dedicated hwmon channel config. The driver can optionally provide the hwmon alarms for each sensor the PVT controller supports. The alarms functionality is made compile-time configurable due to the hardware interface implementation peculiarity, which is connected with an ability to convert data from only one sensor at a time. Additional limitation is that the controller performs the thresholds checking synchronously with the data conversion procedure. Due to these limitations in order to have the hwmon alarms automatically detected the driver code must switch from one sensor to another, read converted data and manually check the threshold status bits. Depending on the measurements timeout settings this design may cause additional burden on the system performance. By default if the alarms kernel config is disabled the data conversion is performed by the driver on demand when read operation is requested via corresponding _input-file. Co-developed-by: Maxim Kaurkin <maxim.kaurkin@baikalelectronics.ru> Signed-off-by: Maxim Kaurkin <maxim.kaurkin@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-28hwmon: Add notification supportGuenter Roeck1-3/+65
For hwmon drivers using the hwmon_device_register_with_info() API, it is desirable to have a generic notification mechanism available. This mechanism can be used to notify userspace as well as the thermal subsystem if the driver experiences any events, such as warning or critical alarms. Implement hwmon_notify_event() to provide this mechanism. The function generates a sysfs event and a udev event. If the device is registered with the thermal subsystem and the event is associated with a temperature sensor, also notify the thermal subsystem that a thermal event occurred. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-mips@vger.kernel.org Cc: devicetree@vger.kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-27hwmon: (applesmc) avoid overlong udelay()Arnd Bergmann1-3/+9
Building this driver with "clang -O3" produces a link error after the compiler partially unrolls the loop and 256ms becomes a compile-time constant that triggers the check in udelay(): ld.lld: error: undefined symbol: __bad_udelay >>> referenced by applesmc.c >>> hwmon/applesmc.o:(read_smc) in archive drivers/built-in.a I can see no reason against using a sleeping function here, as no part of the driver runs in atomic context, so instead use usleep_range() with a wide range and use jiffies for the end condition. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200527135207.1118624-1-arnd@arndb.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-27hwmon: (nct7904) Set default timeoutYuechao Zhao1-4/+4
The timeout module parameter should not be used for setting the default timeout. Because, if you set the timeout = 0, the default timeout will be meaningless. And the timeout module parameter of 0 means "no timeout module parameter specified". Signed-off-by: Yuechao Zhao <yuechao.zhao@advantech.com.cn> Link: https://lore.kernel.org/r/1590560219-41328-1-git-send-email-yuechao.zhao@advantech.com.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-27hwmon: (amd_energy) Missing platform_driver_unregister() on error in ↵Wei Yongjun1-1/+3
amd_energy_init() Add the missing platform_driver_unregister() before return from amd_energy_init() in the error handling case. Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy counters") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Naveen krishna Chatradhi <nchatrad@amd.com> Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20200527022417.105620-1-weiyongjun1@huawei.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-22hwmon: (k10temp) Add AMD family 17h model 60h PCI matchAlexander Monakov1-0/+1
Add support for retrieving Tdie and Tctl on AMD Renoir (4000-series Ryzen CPUs). It appears SMU offsets for reading current/voltage and CCD temperature have changed for this generation (reads from currently used offsets yield zeros), so those features cannot be enabled so trivially. Signed-off-by: Alexander Monakov <amonakov@ispras.ru> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Guenter Roeck <linux@roeck-us.net> Link: https://lkml.kernel.org/r/20200510204842.2603-3-amonakov@ispras.ru
2020-05-22Merge tag 'ib-mfd-hwmon-v5.8' into hwmon-nextGuenter Roeck3-0/+400
Immutable branch between MFD and HWMON due for the v5.8 merge window
2020-05-22hwmon: Add amd_energy driver to report energy countersNaveen Krishna Chatradhi3-0/+417
This patch adds hwmon based amd_energy driver support for family 17h processors from AMD. The driver provides following interface to the userspace 1. Reports the per core consumption * file: "energy%d_input", label: "Ecore%03d" 2. Reports per socket energy consumption * file: "energy%d_input", label: "Esocket%d" 3. To, increase the wrap around time of the socket energy counters, a 64bit accumultor is implemented. 4. Reports scaled energy value in Joules. Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com> Link: https://lore.kernel.org/r/20200519155011.56184-1-nchatrad@amd.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-22hwmon: (nct7802) Replace container_of() APIhailizheng1-3/+3
Replace container_of() API with kobj_to_dev(). Signed-off-by: hailizheng <haili.zheng@powercore.com.cn> Link: https://lore.kernel.org/r/1589891119-16508-1-git-send-email-haili.zheng@powercore.com.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-22hwmon: (lm90) Add max6654 support to lm90 driverJosh Lehan2-8/+46
Add support for the Maxim MAX6654 to the lm90 driver. The MAX6654 is a temperature sensor, similar to the others, but with some differences regarding the configuration register, and the sampling rate at which extended resolution becomes possible. Signed-off-by: Josh Lehan <krellan@google.com> Link: https://lore.kernel.org/r/20200513184248.145765-1-krellan@google.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-22hwmon : (nct6775) Use kobj_to_dev() APIzhouchuangao1-5/+5
Use kobj_to_dev() API instead of container_of(). Signed-off-by: zhouchuangao <zhouchuangao@xiaomi.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-22hwmon: (pmbus) Driver for Maxim MAX16601Guenter Roeck3-0/+324
MAX16601 is a VR13.HC Dual-Output Voltage Regulator Chipset, implementing a (8+1) multiphase synchronous buck converter. Cc: Alex Qiu <xqiu@google.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-22hwmon: (pmbus) Improve initialization of 'currpage' and 'currphase'Guenter Roeck1-4/+4
The 'currpage' and 'currphase' variables in struct pmbus_data are used by the PMBus core to determine if the phase or page value has changed. Both are initialized with values which are never expected to be set in the code to ensure that the first page/phase write operation is actually performed. This is not well explained and occasionally causes confusion. Change the type of both variables to s16 and initialize with -1 to ensure that the initial value never matches a requested value, and clarify that this value means "unknown/unset". Cc: Alex Qiu <xqiu@google.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-22hwmon: (adt7411) update contact emailWolfram Sang1-2/+1
My 'pengutronix' address is defunct for years. Merge the entries and use the proper contact address. Signed-off-by: Wolfram Sang <wsa@kernel.org> Link: https://lore.kernel.org/r/20200502142700.19254-1-wsa@kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-22hwmon: (lm75) Fix all coding-style warnings on lm75 driverMichal Orzel2-16/+23
Check/fix all warnings generated by checkpatch.pl script on LM75 driver. Signed-off-by: Michal Orzel <michalorzel.eng@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-22hwmon: Reduce indentation level in __hwmon_device_register()Akinobu Mita1-26/+42
Reduce indentation level in __hwmon_device_register() by preparing a helper function. This just improves code readability. No functional change. Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-22hwmon: (ina2xx) Implement alert functionsAlex Qiu1-0/+183
Implement alert functions for INA226, INA230 and INA231. Expose 06h Mask/Enable and 07h Alert Limit registers via alert setting and alarm files. Signed-off-by: Alex Qiu <xqiu@google.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-22hwmon: (lm70) Add support for ACPIAndrej Picej1-7/+40
This commit adds support for lm70 commpatible drivers with systems that use ACPI. Signed-off-by: Andrej Picej <andpicej@gmail.com> [groeck: Fix various issues seen if CONFIG_ACPI=n] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-22hwmon: (dell-smm) Use one DMI match for all XPS modelsThomas Hebb1-24/+2
Currently, each new XPS has to be added manually for module autoloading to work. Since fan multiplier autodetection should work fine on all XPS models, just match them all with one block like is done for Precision and Studio. The only match we replace that doesn't already use autodetection is "XPS13" which, according to Google, only matches the XPS 13 9333. (All other XPS 13 models have "XPS" as its own word, surrounded by spaces.) According to the thread at [1], autodetection works for the XPS 13 9333, meaning this shouldn't regress it. I do not own one to confirm with, though. Tested on an XPS 13 9350 and confirmed the module now autoloads and reports reasonable-looking data. I am using BIOS 1.12.2 and do not see any freezes when querying fan speed. [1] https://lore.kernel.org/patchwork/patch/525367/ Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Acked-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/5d7e498b83e89ce7c41a449b61919c65d0770b73.1586033337.git.tommyhebb@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-22hwmon: (nct7904) Add watchdog functionYuechao Zhao2-3/+141
Implement watchdog functionality for NCT7904. Signed-off-by: Yuechao Zhao <yuechao.zhao@advantech.com.cn> Link: https://lore.kernel.org/r/20200331052850.5419-1-yuechao.zhao@advantech.com.cn [groeck: Squashed fixup patch] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-20hwmon: Add Gateworks System Controller supportTim Harvey3-0/+400
The Gateworks System Controller has a hwmon sub-component that exposes up to 16 ADC's, some of which are temperature sensors, others which are voltage inputs. The ADC configuration (register mapping and name) is configured via device-tree and varies board to board. Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2020-05-13hwmon: (da9052) Synchronize access with mfdSamu Nuutamo1-2/+2
When tsi-as-adc is configured it is possible for in7[0123]_input read to return an incorrect value if a concurrent read to in[456]_input is performed. This is caused by a concurrent manipulation of the mux channel without proper locking as hwmon and mfd use different locks for synchronization. Switch hwmon to use the same lock as mfd when accessing the TSI channel. Fixes: 4f16cab19a3d5 ("hwmon: da9052: Add support for TSI channel") Signed-off-by: Samu Nuutamo <samu.nuutamo@vincit.fi> [rebase to current master, reword commit message slightly] Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-13hwmon: (nct7904) Fix incorrect range of temperature limit registersAmy Shih1-1/+3
The format of temperature limitation registers are 8-bit 2's complement and the range is -128~127. Converts the reading value to signed char to fix the incorrect range of temperature limitation registers. Signed-off-by: Amy Shih <amy.shih@advantech.com.tw> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-13hwmon: (nct7904) Read all SMI status registers in probe functionAmy Shih1-0/+8
When nct7904 power up, it compares current sensor readings against the default threshold immediately. This results in false alarms on startup. Read all SMI status registers in probe function to clear the alarms. Signed-off-by: Amy Shih <amy.shih@advantech.com.tw> [groeck: Reworded description] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-09hwmon: (drivetemp) Fix SCT support if SCT data tables are not supportedGuenter Roeck1-1/+1
If SCT is supported but SCT data tables are not, the driver unnecessarily tries to fall back to SMART. Use SCT without data tables instead in this situation. Fixes: 5b46903d8bf3 ("hwmon: Driver for disk and solid state drives with temperature sensors") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-04-18hwmon: (jc42) Fix name to have no illegal charactersSascha Hauer1-1/+1
The jc42 driver passes I2C client's name as hwmon device name. In case of device tree probed devices this ends up being part of the compatible string, "jc-42.4-temp". This name contains hyphens and the hwmon core doesn't like this: jc42 2-0018: hwmon: 'jc-42.4-temp' is not a valid name attribute, please fix This changes the name to "jc42" which doesn't have any illegal characters. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/r/20200417092853.31206-1-s.hauer@pengutronix.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-04-13hwmon: (k10temp) make some symbols staticJason Yan1-3/+3
Fix the following sparse warning: drivers/hwmon/k10temp.c:189:12: warning: symbol 'k10temp_temp_label' was not declared. Should it be static? drivers/hwmon/k10temp.c:202:12: warning: symbol 'k10temp_in_label' was not declared. Should it be static? drivers/hwmon/k10temp.c:207:12: warning: symbol 'k10temp_curr_label' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200409084502.42126-1-yanaijie@huawei.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-04-13hwmon: (drivetemp) Return -ENODATA for invalid temperaturesGuenter Roeck1-0/+6
Holger Hoffstätte observed that Samsung 850 Pro may return invalid temperatures for a short period of time after resume. Return -ENODATA to userspace if this is observed. Fixes: 5b46903d8bf3 ("hwmon: Driver for disk and solid state drives with temperature sensors") Reported-by: Holger Hoffstätte <holger@applied-asynchrony.com> Cc: Holger Hoffstätte <holger@applied-asynchrony.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-04-13hwmon: (drivetemp) Use drivetemp's true module name in Kconfig sectionAnn T Ropea1-1/+1
The addition of the support for reading the temperature of ATA drives as per commit 5b46903d8bf3 ("hwmon: Driver for disk and solid state drives with temperature sensors") lists in the respective Kconfig section the name of the module to be optionally built as "satatemp". However, building the kernel modules with "CONFIG_SENSORS_DRIVETEMP=m", does not generate a file named "satatemp.ko". Instead, the rest of the original commit uses the term "drivetemp" and a file named "drivetemp.ko" ends up in the kernel's modules directory. This file has the right ingredients: $ strings /path/to/drivetemp.ko | grep ^description description=Hard drive temperature monitor and modprobing it produces the expected result: # drivetemp is not loaded $ sensors -u drivetemp-scsi-4-0 Specified sensor(s) not found! $ sudo modprobe drivetemp $ sensors -u drivetemp-scsi-4-0 drivetemp-scsi-4-0 Adapter: SCSI adapter temp1: temp1_input: 35.000 temp1_max: 60.000 temp1_min: 0.000 temp1_crit: 70.000 temp1_lcrit: -40.000 temp1_lowest: 20.000 temp1_highest: 36.000 Fix Kconfig by referring to the true name of the module. Fixes: 5b46903d8bf3 ("hwmon: Driver for disk and solid state drives with temperature sensors") Signed-off-by: Ann T Ropea <bedhanger@gmx.de> Link: https://lore.kernel.org/r/20200406235521.185309-1-bedhanger@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-04-13hwmon: (pmbus/isl68137) Fix up chip IDsGuenter Roeck1-7/+85
I2C chip IDs need to reflect chip names, not chip functionality. Fixes: f621d61fd59f ("hwmon: (pmbus) add support for 2nd Gen Renesas digital multiphase") Cc: Grant Peltier <grantpeltier93@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-04-11change email address for Pali RohárPali Rohár1-2/+2
For security reasons I stopped using gmail account and kernel address is now up-to-date alias to my personal address. People periodically send me emails to address which they found in source code of drivers, so this change reflects state where people can contact me. [ Added .mailmap entry as per Joe Perches - Linus ] Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Joe Perches <joe@perches.com> Link: http://lkml.kernel.org/r/20200307104237.8199-1-pali@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-03-31Merge branch 'perf-core-for-linus' of ↵Linus Torvalds2-5/+5
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf updates from Ingo Molnar: "The main changes in this cycle were: Kernel side changes: - A couple of x86/cpu cleanups and changes were grandfathered in due to patch dependencies. These clean up the set of CPU model/family matching macros with a consistent namespace and C99 initializer style. - A bunch of updates to various low level PMU drivers: * AMD Family 19h L3 uncore PMU * Intel Tiger Lake uncore support * misc fixes to LBR TOS sampling - optprobe fixes - perf/cgroup: optimize cgroup event sched-in processing - misc cleanups and fixes Tooling side changes are to: - perf {annotate,expr,record,report,stat,test} - perl scripting - libapi, libperf and libtraceevent - vendor events on Intel and S390, ARM cs-etm - Intel PT updates - Documentation changes and updates to core facilities - misc cleanups, fixes and other enhancements" * 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (89 commits) cpufreq/intel_pstate: Fix wrong macro conversion x86/cpu: Cleanup the now unused CPU match macros hwrng: via_rng: Convert to new X86 CPU match macros crypto: Convert to new CPU match macros ASoC: Intel: Convert to new X86 CPU match macros powercap/intel_rapl: Convert to new X86 CPU match macros PCI: intel-mid: Convert to new X86 CPU match macros mmc: sdhci-acpi: Convert to new X86 CPU match macros intel_idle: Convert to new X86 CPU match macros extcon: axp288: Convert to new X86 CPU match macros thermal: Convert to new X86 CPU match macros hwmon: Convert to new X86 CPU match macros platform/x86: Convert to new CPU match macros EDAC: Convert to new X86 CPU match macros cpufreq: Convert to new X86 CPU match macros ACPI: Convert to new X86 CPU match macros x86/platform: Convert to new CPU match macros x86/kernel: Convert to new CPU match macros x86/kvm: Convert to new CPU match macros x86/perf/events: Convert to new CPU match macros ...
2020-03-25Merge branch 'x86/cpu' into perf/core, to resolve conflictIngo Molnar2-5/+5
Conflicts: arch/x86/events/intel/uncore.c Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-03-24hwmon: Convert to new X86 CPU match macrosThomas Gleixner2-5/+5
The new macro set has a consistent namespace and uses C99 initializers instead of the grufty C89 ones. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lkml.kernel.org/r/20200320131509.859324598@linutronix.de
2020-03-23hwmon: (pmbus) add support for 2nd Gen Renesas digital multiphaseGrant Peltier2-18/+99
Extend the isl68137 driver to provide support for 2nd generation Renesas digital multiphase voltage regulators. Signed-off-by: Grant Peltier <grantpeltier93@gmail.com> Link: https://lore.kernel.org/r/62c000adf0108aeb65d3f275f28eb26b690384aa.1584720563.git.grantpeltier93@gmail.com [groeck: Adjusted for new PMBus API function parameters] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-15hwmon: (pmbus/ibm-cffps) Add another PSU CCIN to version detectionEddie James1-1/+13
There is an additional CCIN for the IBM CFFPS that may be classifed as either version one or version two, based upon the rest of the bits of the CCIN. Add support for it in the version detection. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/1583948590-17220-1-git-send-email-eajames@linux.ibm.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-15hwmon: (nct7904) Fix the incorrect quantity for fan & temp attributesAmy Shih1-0/+21
nct7904d supports 12 fan tachometers input and 13 temperatures (TEMP_CH1~4 and LTD + DTS TCPU1~8), fix the quantity for fan & temp attributes. Signed-off-by: Amy Shih <amy.shih@advantech.com.tw> Link: https://lore.kernel.org/r/20200312024934.3533-1-Amy.Shih@advantech.com.tw Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-11hwmon: (ibmpowernv) Use scnprintf() for avoiding potential buffer overflowTakashi Iwai1-4/+4
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-09hwmon: (adt7475) Add support for inverting pwm outputChris Packham1-0/+34
Add a "adi,pwm-active-state" device-tree property to allow hardware designs to use inverted logic on the PWM output. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> [groeck: dev_err -> dev_warn] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-09hwmon: (adt7475) Add attenuator bypass supportLogan Shaw1-3/+58
Added support for reading DTS properties to set attenuators on device probe for the ADT7473, ADT7475, ADT7476, and ADT7490. Signed-off-by: Logan Shaw <logan.shaw@alliedtelesis.co.nz> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> [groeck: Continuation line formatting; dev_err -> dev_warn] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-09hwmon: (lm73) Add support for of_match_tableHenry Shen1-0/+10
Add the of_match_table. Signed-off-by: Henry Shen <henry.shen@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20200212030615.28537-3-henry.shen@alliedtelesis.co.nz Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-09hwmon: (pmbus/tps53679) Add support for TPS53647 and TPS53667Guenter Roeck2-4/+15
TPS53647 and TPS53667 are single channel, Step-Down Buck Controllers. TPS53647 supports 4 phases, TPS53667 supports 6 phases. The chips do not support per-phase output telemetry. Cc: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-09hwmon: (pmbus/tps53679) Add support for TPS53681Guenter Roeck2-5/+119
TPS53681 is a dual-channel multiphase step-down controller supporting per-phase and per-channel output telemetry. Cc: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-23 02:38:54 +0300