- 23 Jan, 2020 38 commits
-
-
Guenter Roeck authored
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>
-
Guenter Roeck authored
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:
-
Guenter Roeck authored
Using bitops makes bit masks and shifts easier to read. Tested-by:
-
Akinobu Mita authored
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.comSigned-off-by:
-
Beniamin Bia authored
Add Beniamin Bia and Michael Hennerich as a maintainer for ADM1177 ADC. Signed-off-by:
Beniamin Bia <beniamin.bia@analog.com> Link: https://lore.kernel.org/r/20200114112159.25998-3-beniamin.bia@analog.comSigned-off-by:
-
Beniamin Bia authored
Documentation for ADM1177 was added. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200114112159.25998-2-beniamin.bia@analog.comSigned-off-by:
-
Beniamin Bia authored
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.pdfSigned-off-by:
-
Vadim Pasternak authored
Add documentation for 'xdpe122' devices. Signed-off-by:
Vadim Pasternak <vadimp@mellanox.com> Link: https://lore.kernel.org/r/20200113150841.17670-7-vadimp@mellanox.com [groeck: Added to index.rst] Signed-off-by:
-
Vadim Pasternak authored
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 authored
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 authored
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 authored
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:
-
Eddie James authored
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.comSigned-off-by:
-
YueHaibing authored
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.comSigned-off-by:
-
Guenter Roeck authored
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:
-
Eddie James authored
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 authored
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 authored
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:
-
Guenter Roeck authored
Add support for Maxim MAX20730, MAX20734, MAX20743 Integrated, Step-Down Switching Regulators with PMBus support. Signed-off-by: -
Dr. David Alan Gilbert authored
The 2nd intrusion channel was only used on the nct6776 Signed-off-by:
Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20191225023225.2785-4-linux@treblig.orgSigned-off-by:
-
Dr. David Alan Gilbert authored
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 authored
The nct6775 and nct6776 are supported by the separate nct6775.c driver, so remove the code from the w83627ehf driver. Suggested-by:
-
Guenter Roeck authored
MAX20796 is a dual-phase scalable integrated voltage regulator with PMBus interface. Signed-off-by: -
Chen Zhou authored
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:
Chen Zhou <chenzhou10@huawei.com> Link: https://lore.kernel.org/r/20191213015605.172472-1-chenzhou10@huawei.com [groeck: Dropped all but one log message from description] Signed-off-by:
-
Guenter Roeck authored
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 authored
MAX31730 is a 3-Channel Remote Temperature Sensor. Signed-off-by: -
Guenter Roeck authored
The hwmon ABI supports enable attributes since commit fb41a710 ("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:
-
Dr. David Alan Gilbert authored
Convert the old hwmon_device_register code to devm_hwmon_device_register_with_info. Signed-off-by:
-
Jim Wright authored
Add support for the UCD90320 chip and its expanded set of GPIO pins. Signed-off-by:
Jim Wright <wrightj@linux.vnet.ibm.com> Link: https://lore.kernel.org/r/20191205232411.21492-3-wrightj@linux.vnet.ibm.comSigned-off-by:
-
Jim Wright authored
Document the UCD90320 device tree binding. Signed-off-by:
-
Dr. David Alan Gilbert authored
Add templates for intrusion%d_alarm and intrusion%d_beep. Note, these start at 0. Signed-off-by:
-
git://git.infradead.org/users/willy/linux-daxLinus Torvalds authored
Pull XArray fixes from Matthew Wilcox: "Primarily bugfixes, mostly around handling index wrap-around correctly. A couple of doc fixes and adding missing APIs. I had an oops live on stage at linux.conf.au this year, and it turned out to be a bug in xas_find() which I can't prove isn't triggerable in the current codebase. Then in looking for the bug, I spotted two more bugs. The bots have had a few days to chew on this with no problems reported, and it passes the test-suite (which now has more tests to make sure these problems don't come back)" * tag 'xarray-5.5' of git://git.infradead.org/users/willy/linux-dax: XArray: Add xa_for_each_range XArray: Fix xas_find returning too many entries XArray: Fix xa_find_after with multi-index entries XArray: Fix infinite loop with entry at ULONG_MAX XArray: Add wrappers for nested spinlocks XArray: Improve documentation of search marks XArray: Fix xas_pause at ULONG_MAX
-
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-traceLinus Torvalds authored
Pull tracing fixes from Steven Rostedt: "Various tracing fixes: - Fix a function comparison warning for a xen trace event macro - Fix a double perf_event linking to a trace_uprobe_filter for multiple events - Fix suspicious RCU warnings in trace event code for using list_for_each_entry_rcu() when the "_rcu" portion wasn't needed. - Fix a bug in the histogram code when using the same variable - Fix a NULL pointer dereference when tracefs lockdown enabled and calling trace_set_default_clock() - A fix to a bug found with the double perf_event linking patch" * tag 'trace-v5.5-rc6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing/uprobe: Fix to make trace_uprobe_filter alignment safe tracing: Do not set trace clock if tracefs lockdown is in effect tracing: Fix histogram code when expression has same var as value tracing: trigger: Replace unneeded RCU-list traversals tracing/uprobe: Fix double perf_event linking on multiprobe uprobe tracing: xen: Ordered comparison of function pointers -
https://github.com/ceph/ceph-clientLinus Torvalds authored
Pull ceph fix from Ilya Dryomov: "A fix for a potential use-after-free from Jeff, marked for stable" * tag 'ceph-for-5.5-rc8' of https://github.com/ceph/ceph-client: ceph: hold extra reference to r_parent over life of request
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull power management fix from Rafael Wysocki: "Prevent the kernel from crashing during resume from hibernation if free pages contain leftover data from the restore kernel and init_on_free is set (Alexander Potapenko)" * tag 'pm-5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM: hibernate: fix crashes with init_on_free=1
-
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pciLinus Torvalds authored
Pull PCI fix from Bjorn Helgaas: "Mark ATS as broken on AMD Navi14 GPU rev 0xc5 (Alex Deucher)" * tag 'pci-v5.5-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: Mark AMD Navi14 GPU rev 0xc5 ATS as broken
-
Linus Torvalds authored
In commit 9f79b78e ("Convert filldir[64]() from __put_user() to unsafe_put_user()") I changed filldir to not do individual __put_user() accesses, but instead use unsafe_put_user() surrounded by the proper user_access_begin/end() pair. That make them enormously faster on modern x86, where the STAC/CLAC games make individual user accesses fairly heavy-weight. However, the user_access_begin() range was not really the exact right one, since filldir() has the unfortunate problem that it needs to not only fill out the new directory entry, it also needs to fix up the previous one to contain the proper file offset. It's unfortunate, but the "d_off" field in "struct dirent" is _not_ the file offset of the directory entry itself - it's the offset of the next one. So we end up backfilling the offset in the previous entry as we walk along. But since x86 didn't really care about the exact range, and used to be the only architecture that did anything fancy in user_access_begin() to begin with, the filldir[64]() changes did something lazy, and even commented on it: /* * Note! This range-checks 'previous' (which may be NULL). * The real range was checked in getdents */ if (!user_access_begin(dirent, sizeof(*dirent))) goto efault; and it all worked fine. But now 32-bit ppc is starting to also implement user_access_begin(), and the fact that we faked the range to only be the (possibly not even valid) previous directory entry becomes a problem, because ppc32 will actually be using the range that is passed in for more than just "check that it's user space". This is a complete rewrite of Christophe's original patch. By saving off the record length of the previous entry instead of a pointer to it in the filldir data structures, we can simplify the range check and the writing of the previous entry d_off field. No need for any conditionals in the user accesses themselves, although we retain the conditional EINTR checking for the "was this the first directory entry" signal handling latency logic. Fixes: 9f79b78e ("Convert filldir[64]() from __put_user() to unsafe_put_user()") Link: https://lore.kernel.org/lkml/a02d3426f93f7eb04960a4d9140902d278cab0bb.1579697910.git.christophe.leroy@c-s.fr/ Link: https://lore.kernel.org/lkml/408c90c4068b00ea8f1c41cca45b84ec23d4946b.1579783936.git.christophe.leroy@c-s.fr/Reported-and-tested-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
Commit 8a23eb80 ("Make filldir[64]() verify the directory entry filename is valid") added some minimal validity checks on the directory entries passed to filldir[64](). But they really were pretty minimal. This fleshes out at least the name length check: we used to disallow zero-length names, but really, negative lengths or oevr-long names aren't ok either. Both could happen if there is some filesystem corruption going on. Now, most filesystems tend to use just an "unsigned char" or similar for the length of a directory entry name, so even with a corrupt filesystem you should never see anything odd like that. But since we then use the name length to create the directory entry record length, let's make sure it actually is half-way sensible. Note how POSIX states that the size of a path component is limited by NAME_MAX, but we actually use PATH_MAX for the check here. That's because while NAME_MAX is generally the correct maximum name length (it's 255, for the same old "name length is usually just a byte on disk"), there's nothing in the VFS layer that really cares. So the real limitation at a VFS layer is the total pathname length you can pass as a filename: PATH_MAX. Signed-off-by:
-
- 22 Jan, 2020 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-ledsLinus Torvalds authored
Pull LED fixes from Pavel Machek: "Jacek's fix for an uninitialized gpio label is why I'm requesting this pull; it fixes regression in debugging output in sysfs. Others are just bugfixes that should be safe. Everything has been in -next for while" * tag 'leds-5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: leds: lm3532: add pointer to documentation and fix typo leds: rb532: cleanup whitespace ledtrig-pattern: fix email address quoting in MODULE_AUTHOR() led: max77650: add of_match table leds-as3645a: Drop fwnode reference on ignored node leds: gpio: Fix uninitialized gpio label for fwnode based probe
-
Linus Torvalds authored
Merge tag 'hwmon-for-v5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - In hwmon core, do not use the hwmon parent device for device managed memory allocations, since parent device lifetime may not match hwmon device lifetime. - Fix discrepancy between read and write values in adt7475 driver. - Fix alarms and voltage limits in nct7802 driver. * tag 'hwmon-for-v5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (core) Do not use device managed functions for memory allocations hwmon: (adt7475) Make volt2reg return same reg as reg2volt input hwmon: (nct7802) Fix non-working alarm on voltages hwmon: (nct7802) Fix voltage limits to wrong registers
-
