- 23 Jan, 2020 23 commits
-
-
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 <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/1576788607-13567-4-git-send-email-eajames@linux.ibm.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>
-
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 <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/1576788607-13567-3-git-send-email-eajames@linux.ibm.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>
-
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: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/1576788607-13567-2-git-send-email-eajames@linux.ibm.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>
-
Guenter Roeck authored
Add support for Maxim MAX20730, MAX20734, MAX20743 Integrated, Step-Down Switching Regulators with PMBus support. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
-
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: Guenter Roeck <linux@roeck-us.net>
-
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 <linux@treblig.org> Link: https://lore.kernel.org/r/20191225023225.2785-3-linux@treblig.orgSigned-off-by: Guenter Roeck <linux@roeck-us.net>
-
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 <linux@roeck-us.net> Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20191225023225.2785-2-linux@treblig.orgSigned-off-by: Guenter Roeck <linux@roeck-us.net>
-
Guenter Roeck authored
MAX20796 is a dual-phase scalable integrated voltage regulator with PMBus interface. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
-
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: Hulk Robot <hulkci@huawei.com> Signed-off-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 <linux@roeck-us.net>
-
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 <linux@roeck-us.net>
-
Guenter Roeck authored
MAX31730 is a 3-Channel Remote Temperature Sensor. Signed-off-by: Guenter Roeck <linux@roeck-us.net>
-
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: Guenter Roeck <linux@roeck-us.net>
-
Dr. David Alan Gilbert authored
Convert the old hwmon_device_register code to devm_hwmon_device_register_with_info. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20191124202030.45360-3-linux@treblig.orgSigned-off-by: Guenter Roeck <linux@roeck-us.net>
-
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: Guenter Roeck <linux@roeck-us.net>
-
Jim Wright authored
Document the UCD90320 device tree binding. Signed-off-by: Jim Wright <wrightj@linux.vnet.ibm.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191205232411.21492-2-wrightj@linux.vnet.ibm.comSigned-off-by: Guenter Roeck <linux@roeck-us.net>
-
Dr. David Alan Gilbert authored
Add templates for intrusion%d_alarm and intrusion%d_beep. Note, these start at 0. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20191124202030.45360-2-linux@treblig.orgSigned-off-by: Guenter Roeck <linux@roeck-us.net>
-
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: Linus Torvalds <torvalds@linux-foundation.org>
-
- 22 Jan, 2020 10 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
-
Pavel authored
Add pointer to datasheet and fix typo in printk message. Signed-off-by: Pavel Machek <pavel@ucw.cz>
-
Pavel Machek authored
Trivial cleanup removing empty line at wrong place. Signed-off-by: Pavel Machek <pavel@ucw.cz>
-
Pavel Machek authored
Apparently it is quite easy to forget ">" in quoting of email address. This fixes it. Signed-off-by: Pavel Machek <pavel@ucw.cz>
-
Bartosz Golaszewski authored
We need the of_match table if we want to use the compatible string in the pmic's child node and get the led driver loaded automatically. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
-
Sakari Ailus authored
If a node is ignored, do not get a reference to it. Fix the bug by moving fwnode_handle_get() where a reference to an fwnode is saved for clarity. Reported-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
-
Jacek Anaszewski authored
When switching to using generic LED name composition mechanism via devm_led_classdev_register_ext() API the part of code initializing struct gpio_led's template name property was removed alongside. It was however overlooked that the property was also passed to devm_fwnode_get_gpiod_from_child() in place of "label" parameter, which when set to NULL, results in gpio label being initialized to '?'. It could be observed in debugfs and failed to properly identify gpio association with LED consumer. Fix this shortcoming by updating the GPIO label after the LED is registered and its final name is known. Fixes: d7235f5f ("leds: gpio: Use generic support for composing LED names") Cc: Russell King <linux@armlinux.org.uk> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> [fixed comment] Signed-off-by: Pavel Machek <pavel@ucw.cz>
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull io_uring fix from Jens Axboe: "This was supposed to have gone in last week, but due to a brain fart on my part, I forgot that we made this struct addition in the 5.5 cycle. So here it is for 5.5, to prevent having a 32 vs 64-bit compatability issue with the files_update command" * tag 'io_uring-5.5-2020-01-22' of git://git.kernel.dk/linux-block: io_uring: fix compat for IORING_REGISTER_FILES_UPDATE
-
Masami Hiramatsu authored
Commit 99c9a923 ("tracing/uprobe: Fix double perf_event linking on multiprobe uprobe") moved trace_uprobe_filter on trace_probe_event. However, since it introduced a flexible data structure with char array and type casting, the alignment of trace_uprobe_filter can be broken. This changes the type of the array to trace_uprobe_filter data strucure to fix it. Link: http://lore.kernel.org/r/20200120124022.GA14897@hirez.programming.kicks-ass.net Link: http://lkml.kernel.org/r/157966340499.5107.10978352478952144902.stgit@devnote2 Fixes: 99c9a923 ("tracing/uprobe: Fix double perf_event linking on multiprobe uprobe") Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-
- 21 Jan, 2020 2 commits
-
-
Jeff Layton authored
Currently, we just assume that it will stick around by virtue of the submitter's reference, but later patches will allow the syscall to return early and we can't rely on that reference at that point. While I'm not aware of any reports of it, Xiubo pointed out that this may fix a use-after-free. If the wait for a reply times out or is canceled via signal, and then the reply comes in after the syscall returns, the client can end up trying to access r_parent without a reference. Take an extra reference to the inode when setting r_parent and release it when releasing the request. Cc: stable@vger.kernel.org Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: "Yan, Zheng" <zyan@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
-
Eugene Syromiatnikov authored
fds field of struct io_uring_files_update is problematic with regards to compat user space, as pointer size is different in 32-bit, 32-on-64-bit, and 64-bit user space. In order to avoid custom handling of compat in the syscall implementation, make fds __u64 and use u64_to_user_ptr in order to retrieve it. Also, align the field naturally and check that no garbage is passed there. Fixes: c3a31e60 ("io_uring: add support for IORING_REGISTER_FILES_UPDATE") Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
-
- 20 Jan, 2020 4 commits
-
-
Masami Ichikawa authored
When trace_clock option is not set and unstable clcok detected, tracing_set_default_clock() sets trace_clock(ThinkPad A285 is one of case). In that case, if lockdown is in effect, null pointer dereference error happens in ring_buffer_set_clock(). Link: http://lkml.kernel.org/r/20200116131236.3866925-1-masami256@gmail.com Cc: stable@vger.kernel.org Fixes: 17911ff3 ("tracing: Add locked_down checks to the open calls of files created for tracefs") Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1788488Signed-off-by: Masami Ichikawa <masami256@gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-
Steven Rostedt (VMware) authored
While working on a tool to convert SQL syntex into the histogram language of the kernel, I discovered the following bug: # echo 'first u64 start_time u64 end_time pid_t pid u64 delta' >> synthetic_events # echo 'hist:keys=pid:start=common_timestamp' > events/sched/sched_waking/trigger # echo 'hist:keys=next_pid:delta=common_timestamp-$start,start2=$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' > events/sched/sched_switch/trigger Would not display any histograms in the sched_switch histogram side. But if I were to swap the location of "delta=common_timestamp-$start" with "start2=$start" Such that the last line had: # echo 'hist:keys=next_pid:start2=$start,delta=common_timestamp-$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' > events/sched/sched_switch/trigger The histogram works as expected. What I found out is that the expressions clear out the value once it is resolved. As the variables are resolved in the order listed, when processing: delta=common_timestamp-$start The $start is cleared. When it gets to "start2=$start", it errors out with "unresolved symbol" (which is silent as this happens at the location of the trace), and the histogram is dropped. When processing the histogram for variable references, instead of adding a new reference for a variable used twice, use the same reference. That way, not only is it more efficient, but the order will no longer matter in processing of the variables. From Tom Zanussi: "Just to clarify some more about what the problem was is that without your patch, we would have two separate references to the same variable, and during resolve_var_refs(), they'd both want to be resolved separately, so in this case, since the first reference to start wasn't part of an expression, it wouldn't get the read-once flag set, so would be read normally, and then the second reference would do the read-once read and also be read but using read-once. So everything worked and you didn't see a problem: from: start2=$start,delta=common_timestamp-$start In the second case, when you switched them around, the first reference would be resolved by doing the read-once, and following that the second reference would try to resolve and see that the variable had already been read, so failed as unset, which caused it to short-circuit out and not do the trigger action to generate the synthetic event: to: delta=common_timestamp-$start,start2=$start With your patch, we only have the single resolution which happens correctly the one time it's resolved, so this can't happen." Link: https://lore.kernel.org/r/20200116154216.58ca08eb@gandalf.local.home Cc: stable@vger.kernel.org Fixes: 067fe038 ("tracing: Add variable reference handling to hist triggers") Reviewed-by: Tom Zanuss <zanussi@kernel.org> Tested-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fsLinus Torvalds authored
Pull reiserfs fix from Jan Kara: "A fixup of a recently merged reiserfs fix which has caused problem when xattrs were not compiled in" * tag 'fixes_for_v5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: reiserfs: fix handling of -EOPNOTSUPP in reiserfs_for_each_xattr
-
Linus Torvalds authored
-
- 19 Jan, 2020 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linuxLinus Torvalds authored
Pull RISC-V fixes from Paul Walmsley: "Three fixes for RISC-V: - Don't free and reuse memory containing the code that CPUs parked at boot reside in. - Fix rv64 build problems for ubsan and some modules by adding logical and arithmetic shift helpers for 128-bit values. These are from libgcc and are similar to what's present for ARM64. - Fix vDSO builds to clean up their own temporary files" * tag 'riscv/for-v5.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Less inefficient gcc tishift helpers (and export their symbols) riscv: delete temporary files riscv: make sure the cores stay looping in .Lsecondary_park
-