aboutsummaryrefslogtreecommitdiff
path: root/drivers/hwmon
AgeCommit message (Collapse)AuthorFilesLines
2020-03-08hwmon: (pmbus/tps53679) Add support for multiple chips IDsGuenter Roeck1-10/+31
Chip specific support will be needed in the driver to be able to support additional chips of the same series. Add support for it to the driver. To simplify adding support for more chips, call identification code from the probe function. This lets us use a single structure for common elements of struct pmbus_driver_info, thus reducing code size as support for more chips is added. Cc: Vadim Pasternak <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-03-08hwmon: (pmbus) Implement multi-phase supportGuenter Roeck2-23/+68
Some PMBus chips support multiple phases, and report telemetry such as input current, output current, or temperature for each phase. Add support for such chips to the PMBus core. Start with a maximum of 8 phases per page, and assume that supported sensors per phase are similar for all pages. Only support per-phase telemetry attributes, no limits or alarms. As part of this patch, set the initial page variable to 0xff to ensure that the page is updated when the first page command is issued. Also only issue page commands if the chip supports more than one page. Cc: Vadim Pasternak <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-03-08hwmon: (pmbus) Add 'phase' parameter where needed for multi-phase supportGuenter Roeck18-117/+177
In preparation for multi-phase support, add 'phase' parameter to read_word and set_page functions. Actual multi-phase support will be added in a subsequent patch. Cc: Vadim Pasternak <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-03-08hwmon: (pmbus) Add IC_DEVICE_ID and IC_DEVICE_REV command definitionsGuenter Roeck1-0/+3
Recent PMBus versions added IC_DEVICE_ID and IC_DEVICE_REV commands as additional means to identify the chip. Add command definitions to pmbus.h include file. Cc: Vadim Pasternak <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-03-08hwmon: (ibmaem) Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/r/20200211234237.GA26971@embeddedor Signed-off-by: Guenter Roeck <[email protected]>
2020-03-08hwmon: (k10temp) Reorganize and simplify temperature support detectionGuenter Roeck1-32/+18
Use a bit map to describe if temperature channels are supported, and use it for all temperature channels. Use a separate flag, independent of Tdie support, to indicate if the system is running on a Ryzen CPU. Signed-off-by: Guenter Roeck <[email protected]>
2020-03-08hwmon: (k10temp) Swap Tdie and Tctl on Family 17h CPUsGuenter Roeck1-9/+9
Traditionally, the temperature displayed by k10temp was Tctl. On Family 17h CPUs, Tdie was displayed instead. To reduce confusion, Tctl was added later as second temperature. This resulted in Tdie being reported as temp1_input, and Tctl as temp2_input. This is different to non-Ryzen CPUs, where Tctl is displayed as temp1_input. Swap temp1_input and temp2_input on Family 17h CPUs, such that Tctl is now reported as temp1_input and Tdie is reported as temp2_input, to align with other CPUs, streamline the code, and make it less confusing. Coincidentally, this also aligns the code with its documentation, which states that Tdie is reported as temp2_input. Signed-off-by: Guenter Roeck <[email protected]>
2020-03-08hwmon: (pmbus/ltc2978) add support for more parts.Mike Jones2-9/+96
LTC2972, LTC2979, LTC3884, LTC3889, LTC7880, LTM4664, LTM4677, LTM4678, LTM4680, LTM4700. Signed-off-by: Mike Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] [groeck: Fixed checkpatch issues (long lines, whitespace)] Signed-off-by: Guenter Roeck <[email protected]>
2020-03-08hwmon: Support ADI Fan Control IPNuno Sá3-0/+479
The purpose of this IP Core is to control the fan used for the cooling of a Xilinx Zynq Ultrascale+ MPSoC without the need of any external temperature sensors. To achieve this, the IP core uses the PL SYSMONE4 primitive to obtain the PL temperature and, based on those readings, it then outputs a PWM signal to control the fan rotation accordingly. Signed-off-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] [groeck: adi,pulses-per-revolution -> pulses-per-revolution; dropped unused 'res' from probe function] Signed-off-by: Guenter Roeck <[email protected]>
2020-03-03hwmon: (adt7462) Fix an error return in ADT7462_REG_VOLT()Dan Carpenter1-1/+1
This is only called from adt7462_update_device(). The caller expects it to return zero on error. I fixed a similar issue earlier in commit a4bf06d58f21 ("hwmon: (adt7462) ADT7462_REG_VOLT_MAX() should return 0") but I missed this one. Fixes: c0b4e3ab0c76 ("adt7462: new hwmon driver") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-02-25hwmon: (pmbus/xdpe12284) Add callback for vout limits conversionVadim Pasternak1-0/+54
Provide read_word_data() callback for overvoltage and undervoltage output readouts conversion. These registers are presented in 'slinear11' format, while default conversion for 'vout' class for the devices is 'vid'. It is resulted in wrong conversion in pmbus_reg2data() for in{3-4}_lcrit and in{3-4}_crit attributes. ) Fixes: aaafb7c8eb1c ("hwmon: (pmbus) Add support for Infineon Multi-phase xdpe122 family controllers") Signed-off-by: Vadim Pasternak <[email protected]> Link: https://lore.kernel.org/r/[email protected] [gropeck: Adjusted to mainline PMBus API] Signed-off-by: Guenter Roeck <[email protected]>
2020-02-21hwmon: (w83627ehf) Fix crash seen with W83627DHG-PGuenter Roeck1-1/+6
Loading the driver on a system with W83627DHG-P crashes as follows. w83627ehf: Found W83627DHG-P chip at 0x290 BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 604 Comm: sensors Not tainted 5.6.0-rc2-00055-gca7e1fd1026c #29 Hardware name: /D425KT, BIOS MWPNT10N.86A.0132.2013.0726.1534 07/26/2013 RIP: 0010:w83627ehf_read_string+0x27/0x70 [w83627ehf] Code: [... ] RSP: 0018:ffffb95980657df8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff96caaa7f5218 RCX: 0000000000000000 RDX: 0000000000000015 RSI: 0000000000000001 RDI: ffff96caa736ec08 RBP: 0000000000000000 R08: ffffb95980657e20 R09: 0000000000000001 R10: ffff96caaa635cc0 R11: 0000000000000000 R12: ffff96caa9f7cf00 R13: ffff96caa9ec3d00 R14: ffff96caa9ec3d28 R15: ffff96caa9ec3d40 FS: 00007fbc7c4e2740(0000) GS:ffff96caabc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000129d58000 CR4: 00000000000006f0 Call Trace: ? cp_new_stat+0x12d/0x160 hwmon_attr_show_string+0x37/0x70 [hwmon] dev_attr_show+0x14/0x50 sysfs_kf_seq_show+0xb5/0x1b0 seq_read+0xcf/0x460 vfs_read+0x9b/0x150 ksys_read+0x5f/0xe0 do_syscall_64+0x48/0x190 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... Temperature labels are not always present. Adjust sysfs attribute visibility accordingly. Reported-by: Meelis Roos <[email protected]> Suggested-by: Dr. David Alan Gilbert <[email protected]> Reviewed-by: Dr. David Alan Gilbert <[email protected]> Cc: Meelis Roos <[email protected]> Cc: Dr. David Alan Gilbert <[email protected]> Fixes: 266cd5835947 ("hwmon: (w83627ehf) convert to with_info interface") Signed-off-by: Guenter Roeck <[email protected]>
2020-02-19hwmon: (acpi_power_meter) Fix lockdep splatGuenter Roeck1-8/+8
Damien Le Moal reports a lockdep splat with the acpi_power_meter, observed with Linux v5.5 and later. ====================================================== WARNING: possible circular locking dependency detected 5.6.0-rc2+ #629 Not tainted ------------------------------------------------------ python/1397 is trying to acquire lock: ffff888619080070 (&resource->lock){+.+.}, at: show_power+0x3c/0xa0 [acpi_power_meter] but task is already holding lock: ffff88881643f188 (kn->count#119){++++}, at: kernfs_seq_start+0x6a/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (kn->count#119){++++}: __kernfs_remove+0x626/0x7e0 kernfs_remove_by_name_ns+0x41/0x80 remove_attrs+0xcb/0x3c0 [acpi_power_meter] acpi_power_meter_notify+0x1f7/0x310 [acpi_power_meter] acpi_ev_notify_dispatch+0x198/0x1f3 acpi_os_execute_deferred+0x4d/0x70 process_one_work+0x7c8/0x1340 worker_thread+0x94/0xc70 kthread+0x2ed/0x3f0 ret_from_fork+0x24/0x30 -> #0 (&resource->lock){+.+.}: __lock_acquire+0x20be/0x49b0 lock_acquire+0x127/0x340 __mutex_lock+0x15b/0x1350 show_power+0x3c/0xa0 [acpi_power_meter] dev_attr_show+0x3f/0x80 sysfs_kf_seq_show+0x216/0x410 seq_read+0x407/0xf90 vfs_read+0x152/0x2c0 ksys_read+0xf3/0x1d0 do_syscall_64+0x95/0x1010 entry_SYSCALL_64_after_hwframe+0x49/0xbe other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(kn->count#119); lock(&resource->lock); lock(kn->count#119); lock(&resource->lock); *** DEADLOCK *** 4 locks held by python/1397: #0: ffff8890242d64e0 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x9b/0xb0 #1: ffff889040be74e0 (&p->lock){+.+.}, at: seq_read+0x6b/0xf90 #2: ffff8890448eb880 (&of->mutex){+.+.}, at: kernfs_seq_start+0x47/0x160 #3: ffff88881643f188 (kn->count#119){++++}, at: kernfs_seq_start+0x6a/0x160 stack backtrace: CPU: 10 PID: 1397 Comm: python Not tainted 5.6.0-rc2+ #629 Hardware name: Supermicro Super Server/X11DPL-i, BIOS 3.1 05/21/2019 Call Trace: dump_stack+0x97/0xe0 check_noncircular+0x32e/0x3e0 ? print_circular_bug.isra.0+0x1e0/0x1e0 ? unwind_next_frame+0xb9a/0x1890 ? entry_SYSCALL_64_after_hwframe+0x49/0xbe ? graph_lock+0x79/0x170 ? __lockdep_reset_lock+0x3c0/0x3c0 ? mark_lock+0xbc/0x1150 __lock_acquire+0x20be/0x49b0 ? mark_held_locks+0xe0/0xe0 ? stack_trace_save+0x91/0xc0 lock_acquire+0x127/0x340 ? show_power+0x3c/0xa0 [acpi_power_meter] ? device_remove_bin_file+0x10/0x10 ? device_remove_bin_file+0x10/0x10 __mutex_lock+0x15b/0x1350 ? show_power+0x3c/0xa0 [acpi_power_meter] ? show_power+0x3c/0xa0 [acpi_power_meter] ? mutex_lock_io_nested+0x11f0/0x11f0 ? lock_downgrade+0x6a0/0x6a0 ? kernfs_seq_start+0x47/0x160 ? lock_acquire+0x127/0x340 ? kernfs_seq_start+0x6a/0x160 ? device_remove_bin_file+0x10/0x10 ? show_power+0x3c/0xa0 [acpi_power_meter] show_power+0x3c/0xa0 [acpi_power_meter] dev_attr_show+0x3f/0x80 ? memset+0x20/0x40 sysfs_kf_seq_show+0x216/0x410 seq_read+0x407/0xf90 ? security_file_permission+0x16f/0x2c0 vfs_read+0x152/0x2c0 Problem is that reading an attribute takes the kernfs lock in the kernfs code, then resource->lock in the driver. During an ACPI notification, the opposite happens: The resource lock is taken first, followed by the kernfs lock when sysfs attributes are removed and re-created. Presumably this is now seen due to some locking related changes in kernfs after v5.4, but it was likely always a problem. Fix the problem by not blindly acquiring the lock in the notification function. It is only needed to protect the various update functions. However, those update functions are called anyway when sysfs attributes are read. This means that we can just stop calling those functions from the notifier, and the resource lock in the notifier function is no longer needed. That leaves two situations: First, METER_NOTIFY_CONFIG removes and re-allocates capability strings. While it did so under the resource lock, _displaying_ those strings was not protected, creating a race condition. To solve this problem, selectively protect both removal/creation and reporting of capability attributes with the resource lock. Second, removing and re-creating the attribute files is no longer protected by the resource lock. That doesn't matter since access to each individual attribute is protected by the kernfs lock. Userspace may get messed up if attributes disappear and reappear under its nose, but that is not different than today, and there is nothing we can do about it without major driver restructuring. Last but not least, when removing the driver, remove attribute functions first, then release capability strings. This avoids yet another race condition. Reported-by: Damien Le Moal <[email protected]> Cc: Damien Le Moal <[email protected]> Cc: [email protected] # v5.5+ Tested-by: Damien Le Moal <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-02-12hwmon: (pmbus/xdpe12284) fix typo in compatible stringsJohan Hovold1-2/+2
Make sure that the driver compatible strings matches the binding by removing the space between the manufacturer and model. Fixes: aaafb7c8eb1c ("hwmon: (pmbus) Add support for Infineon Multi-phase xdpe122 family controllers") Cc: Vadim Pasternak <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-02-09hwmon: (pmbus/ltc2978) Fix PMBus polling of MFR_COMMON definitions.Mike Jones1-2/+2
Change 21537dc driver PMBus polling of MFR_COMMON from bits 5/4 to bits 6/5. This fixs a LTC297X family bug where polling always returns not busy even when the part is busy. This fixes a LTC388X and LTM467X bug where polling used PEND and NOT_IN_TRANS, and BUSY was not polled, which can lead to NACKing of commands. LTC388X and LTM467X modules now poll BUSY and PEND, increasing reliability by eliminating NACKing of commands. Signed-off-by: Mike Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: e04d1ce9bbb49 ("hwmon: (ltc2978) Add polling for chips requiring it") Signed-off-by: Guenter Roeck <[email protected]>
2020-02-08Merge tag 'armsoc-drivers' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC-related driver updates from Olof Johansson: "Various driver updates for platforms: - Nvidia: Fuse support for Tegra194, continued memory controller pieces for Tegra30 - NXP/FSL: Refactorings of QuickEngine drivers to support ARM/ARM64/PPC - NXP/FSL: i.MX8MP SoC driver pieces - TI Keystone: ring accelerator driver - Qualcomm: SCM driver cleanup/refactoring + support for new SoCs. - Xilinx ZynqMP: feature checking interface for firmware. Mailbox communication for power management - Overall support patch set for cpuidle on more complex hierarchies (PSCI-based) and misc cleanups, refactorings of Marvell, TI, other platforms" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (166 commits) drivers: soc: xilinx: Use mailbox IPI callback dt-bindings: power: reset: xilinx: Add bindings for ipi mailbox drivers: soc: ti: knav_qmss_queue: Pass lockdep expression to RCU lists MAINTAINERS: Add brcmstb PCIe controller entry soc/tegra: fuse: Unmap registers once they are not needed anymore soc/tegra: fuse: Correct straps' address for older Tegra124 device trees soc/tegra: fuse: Warn if straps are not ready soc/tegra: fuse: Cache values of straps and Chip ID registers memory: tegra30-emc: Correct error message for timed out auto calibration memory: tegra30-emc: Firm up hardware programming sequence memory: tegra30-emc: Firm up suspend/resume sequence soc/tegra: regulators: Do nothing if voltage is unchanged memory: tegra: Correct reset value of xusb_hostr soc/tegra: fuse: Add APB DMA dependency for Tegra20 bus: tegra-aconnect: Remove PM_CLK dependency dt-bindings: mediatek: add MT6765 power dt-bindings soc: mediatek: cmdq: delete not used define memory: tegra: Add support for the Tegra194 memory controller memory: tegra: Only include support for enabled SoCs memory: tegra: Support DVFS on Tegra186 and later ...
2020-02-04proc: convert everything to "struct proc_ops"Alexey Dobriyan1-8/+7
The most notable change is DEFINE_SHOW_ATTRIBUTE macro split in seq_file.h. Conversion rule is: llseek => proc_lseek unlocked_ioctl => proc_ioctl xxx => proc_xxx delete ".owner = THIS_MODULE" line [[email protected]: fix drivers/isdn/capi/kcapi_proc.c] [[email protected]: fix kernel/sched/psi.c] Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/20191225172546.GB13378@avx2 Signed-off-by: Alexey Dobriyan <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-01-27Merge tag 'ioremap-5.6' of git://git.infradead.org/users/hch/ioremapLinus Torvalds1-1/+1
Pull ioremap updates from Christoph Hellwig: "Remove the ioremap_nocache API (plus wrappers) that are always identical to ioremap" * tag 'ioremap-5.6' of git://git.infradead.org/users/hch/ioremap: remove ioremap_nocache and devm_ioremap_nocache MIPS: define ioremap_nocache to ioremap
2020-01-23hwmon: (k10temp) Display up to eight sets of CCD temperaturesGuenter Roeck1-41/+41
In HWiNFO, we see support for Tccd1, Tccd3, Tccd5, and Tccd7 temperature sensors on Zen2 based Threadripper CPUs. Checking register maps on Threadripper 3970X confirms SMN register addresses and values for those sensors. Register values observed in an idle system: 0x059950: 00000000 00000abc 00000000 00000ad8 0x059960: 00000000 00000ade 00000000 00000ae4 Under load: 0x059950: 00000000 00000c02 00000000 00000c14 0x059960: 00000000 00000c30 00000000 00000c22 More analysis shows that EPYC CPUs support up to 8 CCD temperature sensors. EPYC 7601 supports three CCD temperature sensors. Unlike Zen2 CPUs, the register space in Zen1 CPUs supports a maximum of four sensors, so only search for a maximum of four sensors on Zen1 CPUs. On top of that, in thm_10_0_sh_mask.h in the Linux kernel, we find definitions for THM_DIE{1-3}_TEMP__VALID_MASK, set to 0x00000800, as well as matching SMN addresses. This lets us conclude that bit 11 of the respective registers is a valid bit. With this assumption, the temperature offset is now 49 degrees C. This conveniently matches the documented temperature offset for Tdie, again suggesting that above registers indeed report temperatures sensor values. Assume that bit 11 is indeed a valid bit, and add support for the additional sensors. With this patch applied, output from 3970X (idle) looks as follows: k10temp-pci-00c3 Adapter: PCI adapter Tdie: +55.9°C Tctl: +55.9°C Tccd1: +39.8°C Tccd3: +43.8°C Tccd5: +43.8°C Tccd7: +44.8°C Tested-by: Michael Larabel <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (k10temp) Add debugfs supportGuenter Roeck1-1/+77
Show thermal and SVI registers for Family 17h CPUs. Tested-by: Sebastian Reichel <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (k10temp) Don't show temperature limits on Ryzen (Zen) CPUsGuenter Roeck1-1/+1
The maximum Tdie or Tctl is not published for Ryzen CPUs. What is known, however, is that the traditional value of 70 degrees C is no longer correct. On top of that, the limit applies to Tctl, not to Tdie. Displaying it in either context is meaningless, confusing, and wrong. Stop doing it. Tested-by: Brad Campbell <[email protected]> Tested-by: Holger Kiehl <[email protected]> Tested-by: Michael Larabel <[email protected]> Tested-by: Jonathan McDowell <[email protected]> Tested-by: Ken Moffat <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (k10temp) Show core and SoC current and voltages on Ryzen CPUsGuenter Roeck1-3/+131
Ryzen CPUs report core and SoC voltages and currents. Add support for it to the k10temp driver. For the time being, only report voltages and currents for Ryzen CPUs. Threadripper and EPYC appear to use a different mechanism. Tested-by: Brad Campbell <[email protected]> Tested-by: Bernhard Gebetsberger <[email protected]> Tested-by: Holger Kiehl <[email protected]> Tested-by: Michael Larabel <[email protected]> Tested-by: Jonathan McDowell <[email protected]> Tested-by: Ken Moffat <[email protected]> Tested-by: Darren Salt <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (k10temp) Report temperatures per CPU dieGuenter Roeck1-1/+79
Zen2 reports reporting temperatures per CPU die (called Core Complex Dies, or CCD, by AMD). Add support for it to the k10temp driver. Tested-by: Brad Campbell <[email protected]> Tested-by: Bernhard Gebetsberger <[email protected]> Tested-by: Holger Kiehl <[email protected]> Tested-by: Michael Larabel <[email protected]> Tested-by: Jonathan McDowell <[email protected]> Tested-by: Ken Moffat <[email protected]> Tested-by: Darren Salt <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hmon: (k10temp) Convert to use devm_hwmon_device_register_with_infoGuenter Roeck1-101/+112
Convert driver to use devm_hwmon_device_register_with_info to simplify the code and to reduce its size. Old size (x86_64): text data bss dec hex filename 8247 4488 64 12799 31ff drivers/hwmon/k10temp.o New size: text data bss dec hex filename 6778 2792 64 9634 25a2 drivers/hwmon/k10temp.o Tested-by: Brad Campbell <[email protected]> Tested-by: Bernhard Gebetsberger <[email protected]> Tested-by: Holger Kiehl <[email protected]> Tested-by: Michael Larabel <[email protected]> Tested-by: Jonathan McDowell <[email protected]> Tested-by: Ken Moffat <[email protected]> Tested-by: Darren Salt <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (k10temp) Use bitopsGuenter Roeck1-6/+10
Using bitops makes bit masks and shifts easier to read. Tested-by: Brad Campbell <[email protected]> Tested-by: Bernhard Gebetsberger <[email protected]> Tested-by: Holger Kiehl <[email protected]> Tested-by: Michael Larabel <[email protected]> Tested-by: Jonathan McDowell <[email protected]> Tested-by: Ken Moffat <[email protected]> Tested-by: Darren Salt <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (pwm-fan) stop fan on shutdownAkinobu Mita1-2/+13
The pwm-fan driver stops the fan in suspend but leaves the fan on in shutdown. It seems strange to leave the fan on in shutdown because there is no use case in my mind and the gpio-fan driver on the other hand stops in shutdown. This change turns off the fan in shutdown. If anyone complains then we'll add an optional property to switch the behavior. Cc: Rob Herring <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Kamil Debski <[email protected]> Cc: Bartlomiej Zolnierkiewicz <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: Thierry Reding <[email protected]> Cc: Uwe Kleine-König <[email protected]> Signed-off-by: Akinobu Mita <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (adm1177) Add ADM1177 Hot Swap Controller and Digital Power Monitor ↵Beniamin Bia3-0/+299
driver ADM1177 is a Hot Swap Controller and Digital Power Monitor with Soft Start Pin. Datasheet: Link: https://www.analog.com/media/en/technical-documentation/data-sheets/ADM1177.pdf Signed-off-by: Beniamin Bia <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (pmbus) Add support for Infineon Multi-phase xdpe122 family controllersVadim Pasternak3-0/+127
Add support for devices XDPE12254, XDPE12284. All these device support two pages. The below lists of VOUT_MODE command readout with their related VID protocols, Digital to Analog Converter steps, supported by these devices: VR12.0 mode, 5-mV DAC - 0x01; VR12.5 mode, 10-mV DAC - 0x02; IMVP9 mode, 5-mV DAC - 0x03; AMD mode 6.25mV - 0x10. Signed-off-by: Vadim Pasternak <[email protected]> Link: https://lore.kernel.org/r/[email protected] [groeck: Added missing break statement] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (pmbus/tps53679) Extend device list supported by driverVadim Pasternak2-2/+4
Extends driver with support of the additional devices: Texas Instruments Dual channel DCAP+ multiphase controllers: TPS53688. Extend Kconfig with added device. Signed-off-by: Vadim Pasternak <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (pmbus/core) Add support for Intel IMVP9 and AMD 6.25mV modesVadim Pasternak2-1/+9
Extend "vrm_version" with the type for Intel IMVP9 and AMD 6.25mV VID modes. Add calculation for those types. Signed-off-by: Vadim Pasternak <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (pmbus/core) Add support for vid mode detection per page basesVadim Pasternak6-46/+53
Add support for VID protocol detection per page bases, instead of detecting it based on "PMBU_VOUT" readout from page 0 for all the pages supported by particular device. The reason that some devices allows to configure different VID modes per page within the same device. Patch modifies the field "vrm_version" within the structure "pmbus_driver_info" to be per page array. Signed-off-by: Vadim Pasternak <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (pmbus/ibm-cffps) Prevent writing on_off_config with bad dataEddie James1-1/+1
If the user write parameters resulted in no bytes being written to the temporary buffer, then ON_OFF_CONFIG will be written with uninitialized data. Prevent this by bailing out in this case. Signed-off-by: Eddie James <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (w83627ehf) Remove set but not used variable 'fan4min'YueHaibing1-3/+1
Fixes gcc '-Wunused-but-set-variable' warning: drivers/hwmon/w83627ehf.c: In function 'w83627ehf_check_fan_inputs': drivers/hwmon/w83627ehf.c:1296:24: warning: variable 'fan4min' set but not used [-Wunused-but-set-variable] commit 62000264cfa8 ("hwmon: (w83627ehf) remove nct6775 and nct6776 support") left behind this unused variable. Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: Driver for disk and solid state drives with temperature sensorsGuenter Roeck3-0/+585
Reading the temperature of ATA drives has been supported for years by userspace tools such as smarttools or hddtemp. The downside of such tools is that they need to run with super-user privilege, that the temperatures are not reported by standard tools such as 'sensors' or 'libsensors', and that drive temperatures are not available for use in the kernel's thermal subsystem. This driver solves this problem by adding support for reading the temperature of ATA drives from the kernel using the hwmon API and by adding a temperature zone for each drive. With this driver, the hard disk temperature can be read using the unprivileged 'sensors' application: $ sensors drivetemp-scsi-1-0 drivetemp-scsi-1-0 Adapter: SCSI adapter temp1: +23.0°C or directly from sysfs: $ grep . /sys/class/hwmon/hwmon9/{name,temp1_input} /sys/class/hwmon/hwmon9/name:drivetemp /sys/class/hwmon/hwmon9/temp1_input:23000 If the drive supports SCT transport and reports temperature limits, those are reported as well. drivetemp-scsi-0-0 Adapter: SCSI adapter temp1: +27.0°C (low = +0.0°C, high = +60.0°C) (crit low = -41.0°C, crit = +85.0°C) (lowest = +23.0°C, highest = +34.0°C) The driver attempts to use SCT Command Transport to read the drive temperature. If the SCT Command Transport feature set is not available, or if it does not report the drive temperature, drive temperatures may be readable through SMART attributes. Since SMART attributes are not well defined, this method is only used as fallback mechanism. Cc: Chris Healy <[email protected]> Cc: Linus Walleij <[email protected]> Cc: Martin K. Petersen <[email protected]> Cc: Bart Van Assche <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Tested-by: Linus Walleij <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (pmbus/ibm-cffps) Fix the LED behavior when turned offEddie James1-5/+4
The driver should remain in control of the LED on the PSU, even while off, not the PSU firmware as previously indicated. Signed-off-by: Eddie James <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (pmbus/ibm-cffps) Add the VMON property for version 2Eddie James1-1/+5
Version 2 of the PSU supports reading an auxiliary voltage. Use the pmbus VMON property and associated virtual register to read it. Signed-off-by: Eddie James <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (pmbus/ibm-cffps) Add new manufacturer debugfs entriesEddie James1-4/+70
Add support for a number of manufacturer-specific registers in the debugfs entries, as well as support to read and write the PMBUS_ON_OFF_CONFIG register through debugfs. Signed-off-by: Eddie James <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (pmbus) Driver for MAX20730, MAX20734, and MAX20743Guenter Roeck3-0/+382
Add support for Maxim MAX20730, MAX20734, MAX20743 Integrated, Step-Down Switching Regulators with PMBus support. Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (w83627ehf) Now only one intrusion channelDr. David Alan Gilbert1-13/+6
The 2nd intrusion channel was only used on the nct6776 Signed-off-by: Dr. David Alan Gilbert <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (w83627ehf) Remove code not needed after nct677* removalDr. David Alan Gilbert1-106/+32
Now the nct677* are gone, we can clean up some flags that are always the same now and simplify some code. Signed-off-by: Dr. David Alan Gilbert <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (w83627ehf) remove nct6775 and nct6776 supportDr. David Alan Gilbert2-441/+41
The nct6775 and nct6776 are supported by the separate nct6775.c driver, so remove the code from the w83627ehf driver. Suggested-by: Guenter Roeck <[email protected]> Signed-off-by: Dr. David Alan Gilbert <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (pmbus) Add MAX20796 to devices supported by generic pmbus driverGuenter Roeck2-2/+3
MAX20796 is a dual-phase scalable integrated voltage regulator with PMBus interface. Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (w83627ehf) make sensor_dev_attr_##_name variables staticChen Zhou1-28/+28
Fix sparse warning: drivers/hwmon/w83627ehf.c:1202:1: warning: symbol 'sensor_dev_attr_pwm1_target' was not declared. Should it be static? and many more similar messages. Reported-by: Hulk Robot <[email protected]> Signed-off-by: Chen Zhou <[email protected]> Link: https://lore.kernel.org/r/[email protected] [groeck: Dropped all but one log message from description] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (pmbus) Detect if chip is write protectedGuenter Roeck2-0/+23
If a chip is write protected, we can not change any limits, and we can not clear status flags. This may be the reason why clearing status flags is reported to not work for some chips. Detect the condition in the pmbus core. If the chip is write protected, set limit attributes as read-only, and set the flag indicating that the status flag should be ignored. Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: Driver for MAX31730Guenter Roeck3-1/+452
MAX31730 is a 3-Channel Remote Temperature Sensor. Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: Add support for enable attributes to hwmon coreGuenter Roeck1-1/+7
The hwmon ABI supports enable attributes since commit fb41a710f84e ("hwmon: Document the sensor enable attribute"), but did not add support for those attributes to the hwmon core. Do that now. Since the enable attributes are logically the most important attributes, they are added as first attribute to the attribute list. Move hwmon_in_enable from last to first place for consistency. Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (w83627ehf) convert to with_info interfaceDr. David Alan Gilbert1-799/+630
Convert the old hwmon_device_register code to devm_hwmon_device_register_with_info. Signed-off-by: Dr. David Alan Gilbert <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: (pmbus/ucd9000) Add support for UCD90320 Power SequencerJim Wright2-15/+30
Add support for the UCD90320 chip and its expanded set of GPIO pins. Signed-off-by: Jim Wright <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-23hwmon: Add intrusion templatesDr. David Alan Gilbert1-1/+8
Add templates for intrusion%d_alarm and intrusion%d_beep. Note, these start at 0. Signed-off-by: Dr. David Alan Gilbert <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-01-17hwmon: (core) Do not use device managed functions for memory allocationsGuenter Roeck1-27/+41
The hwmon core uses device managed functions, tied to the hwmon parent device, for various internal memory allocations. This is problematic since hwmon device lifetime does not necessarily match its parent's device lifetime. If there is a mismatch, memory leaks will accumulate until the parent device is released. Fix the problem by managing all memory allocations internally. The only exception is memory allocation for thermal device registration, which can be tied to the hwmon device, along with thermal device registration itself. Fixes: d560168b5d0f ("hwmon: (core) New hwmon registration API") Cc: [email protected] # v4.14.x: 47c332deb8e8: hwmon: Deal with errors from the thermal subsystem Cc: [email protected] # v4.14.x: 74e3512731bd: hwmon: (core) Fix double-free in __hwmon_device_register() Cc: [email protected] # v4.9.x: 3a412d5e4a1c: hwmon: (core) Simplify sysfs attribute name allocation Cc: [email protected] # v4.9.x: 47c332deb8e8: hwmon: Deal with errors from the thermal subsystem Cc: [email protected] # v4.9.x: 74e3512731bd: hwmon: (core) Fix double-free in __hwmon_device_register() Cc: [email protected] # v4.9+ Cc: Martin K. Petersen <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.