summaryrefslogtreecommitdiff
path: root/drivers/hwmon
AgeCommit message (Collapse)AuthorFilesLines
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>
2020-03-09hwmon: (pmbus/tps53679) Add support for IIN and PIN to TPS53679 and TPS53688Guenter Roeck1-3/+3
All chips of this series with published datasheets support IIN, PIN, and STATUS_INPUT PMBus commands. Per TI Power Management Forum, "TPS53679 and TPS53681 have the same PMBus command set". There is no reason to believe that this does not apply to TPS53688. Let's assume that this is correct and add support for IIN, PIN, and STATUS_INPUT to TPS53679 and TPS53688 to simplify adding support for more chips of the same series. At the same time, drop reporting VIN on channel 2. On chips with published datasheets this voltage is identical to the voltage reported on channel 1, and there is no reason to believe that this is different for TPS53679 and TPS53888. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-09hwmon: (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 <vadimp@mellanox.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-09hwmon: (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 <vadimp@mellanox.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-09hwmon: (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 <vadimp@mellanox.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-09hwmon: (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 <vadimp@mellanox.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-09hwmon: (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 <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200211234237.GA26971@embeddedor Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-09hwmon: (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 <linux@roeck-us.net>
2020-03-09hwmon: (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 <linux@roeck-us.net>
2020-03-09hwmon: (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 <michael-a1.jones@analog.com> Link: https://lore.kernel.org/r/1581032654-4330-1-git-send-email-michael-a1.jones@analog.com [groeck: Fixed checkpatch issues (long lines, whitespace)] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-03-09hwmon: 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á <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20191009102806.262241-1-nuno.sa@analog.com [groeck: adi,pulses-per-revolution -> pulses-per-revolution; dropped unused 'res' from probe function] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
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 <dan.carpenter@oracle.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Link: https://lore.kernel.org/r/20200303101608.kqjwfcazu2ylhi2a@kili.mountain Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-02-26hwmon: (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 <vadimp@mellanox.com> Link: https://lore.kernel.org/r/20200224225202.19576-1-vadimp@mellanox.com [gropeck: Adjusted to mainline PMBus API] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
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 <mroos@linux.ee> Suggested-by: Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by: Dr. David Alan Gilbert <linux@treblig.org> Cc: Meelis Roos <mroos@linux.ee> Cc: Dr. David Alan Gilbert <linux@treblig.org> Fixes: 266cd5835947 ("hwmon: (w83627ehf) convert to with_info interface") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-02-20hwmon: (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 <Damien.LeMoal@wdc.com> Cc: Damien Le Moal <Damien.LeMoal@wdc.com> Cc: stable@vger.kernel.org # v5.5+ Tested-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
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 <vadimp@mellanox.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20200212092426.24012-1-johan@kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-02-10hwmon: (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 <michael-a1.jones@analog.com> Link: https://lore.kernel.org/r/1580234400-2829-2-git-send-email-michael-a1.jones@analog.com Fixes: e04d1ce9bbb49 ("hwmon: (ltc2978) Add polling for chips requiring it") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-02-09Merge 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 [akpm@linux-foundation.org: fix drivers/isdn/capi/kcapi_proc.c] [sfr@canb.auug.org.au: fix kernel/sched/psi.c] Link: http://lkml.kernel.org/r/20200122180545.36222f50@canb.auug.org.au Link: http://lkml.kernel.org/r/20191225172546.GB13378@avx2 Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-01-28Merge 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-24hwmon: (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 <michael@phoronix.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (k10temp) Add debugfs supportGuenter Roeck1-1/+77
Show thermal and SVI registers for Family 17h CPUs. Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (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 <lists2009@fnarfbargle.com> Tested-by: Holger Kiehl <holger.kiehl@dwd.de> Tested-by: Michael Larabel <michael@phoronix.com> Tested-by: Jonathan McDowell <noodles@earth.li> Tested-by: Ken Moffat <zarniwhoop73@googlemail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (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 <lists2009@fnarfbargle.com> Tested-by: Bernhard Gebetsberger <bernhard.gebetsberger@gmx.at> Tested-by: Holger Kiehl <holger.kiehl@dwd.de> Tested-by: Michael Larabel <michael@phoronix.com> Tested-by: Jonathan McDowell <noodles@earth.li> Tested-by: Ken Moffat <zarniwhoop73@googlemail.com> Tested-by: Darren Salt <devspam@moreofthesa.me.uk> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (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 <lists2009@fnarfbargle.com> Tested-by: Bernhard Gebetsberger <bernhard.gebetsberger@gmx.at> Tested-by: Holger Kiehl <holger.kiehl@dwd.de> Tested-by: Michael Larabel <michael@phoronix.com> Tested-by: Jonathan McDowell <noodles@earth.li> Tested-by: Ken Moffat <zarniwhoop73@googlemail.com> Tested-by: Darren Salt <devspam@moreofthesa.me.uk> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hmon: (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 <lists2009@fnarfbargle.com> Tested-by: Bernhard Gebetsberger <bernhard.gebetsberger@gmx.at> Tested-by: Holger Kiehl <holger.kiehl@dwd.de> Tested-by: Michael Larabel <michael@phoronix.com> Tested-by: Jonathan McDowell <noodles@earth.li> Tested-by: Ken Moffat <zarniwhoop73@googlemail.com> Tested-by: Darren Salt <devspam@moreofthesa.me.uk> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (k10temp) Use bitopsGuenter Roeck1-6/+10
Using bitops makes bit masks and shifts easier to read. Tested-by: Brad Campbell <lists2009@fnarfbargle.com> Tested-by: Bernhard Gebetsberger <bernhard.gebetsberger@gmx.at> Tested-by: Holger Kiehl <holger.kiehl@dwd.de> Tested-by: Michael Larabel <michael@phoronix.com> Tested-by: Jonathan McDowell <noodles@earth.li> Tested-by: Ken Moffat <zarniwhoop73@googlemail.com> Tested-by: Darren Salt <devspam@moreofthesa.me.uk> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (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 <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Kamil Debski <kamil@wypas.org> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Link: https://lore.kernel.org/r/1579534344-11694-1-git-send-email-akinobu.mita@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (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 <beniamin.bia@analog.com> Link: https://lore.kernel.org/r/20200114112159.25998-1-beniamin.bia@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (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 <vadimp@mellanox.com> Link: https://lore.kernel.org/r/20200113150841.17670-5-vadimp@mellanox.com [groeck: Added missing break statement] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (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 <vadimp@mellanox.com> Link: https://lore.kernel.org/r/20200113150841.17670-4-vadimp@mellanox.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (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 <vadimp@mellanox.com> Link: https://lore.kernel.org/r/20200113150841.17670-3-vadimp@mellanox.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (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 <vadimp@mellanox.com> Link: https://lore.kernel.org/r/20200113150841.17670-2-vadimp@mellanox.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (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 <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/1578411640-16929-1-git-send-email-eajames@linux.ibm.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (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 <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200108034514.50130-1-yuehaibing@huawei.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: 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 <cphealy@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (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 <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/1576788607-13567-4-git-send-email-eajames@linux.ibm.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-01-24hwmon: (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 <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/1576788607-13567-3-git-send-email-eajames@linux.ibm.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-17 15:40:26 +0300