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: NVadim Pasternak <vadimp@mellanox.com>
Link: https://lore.kernel.org/r/20200113150841.17670-5-vadimp@mellanox.com
[groeck: Added missing break statement]
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

Extends driver with support of the additional devices:
Texas Instruments Dual channel DCAP+ multiphase controllers: TPS53688.

Extend Kconfig with added device.
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
Link: https://lore.kernel.org/r/20200113150841.17670-4-vadimp@mellanox.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

Extend "vrm_version" with the type for Intel IMVP9 and AMD 6.25mV VID
modes.
Add calculation for those types.
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
Link: https://lore.kernel.org/r/20200113150841.17670-3-vadimp@mellanox.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NVadim Pasternak <vadimp@mellanox.com>
Link: https://lore.kernel.org/r/20200113150841.17670-2-vadimp@mellanox.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NEddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/1578411640-16929-1-git-send-email-eajames@linux.ibm.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200108034514.50130-1-yuehaibing@huawei.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NEddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/1576788607-13567-4-git-send-email-eajames@linux.ibm.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NEddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/1576788607-13567-3-git-send-email-eajames@linux.ibm.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NEddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/1576788607-13567-2-git-send-email-eajames@linux.ibm.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

Add support for Maxim MAX20730, MAX20734, MAX20743 Integrated,
Step-Down Switching Regulators with PMBus support.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

The 2nd intrusion channel was only used on the nct6776
Signed-off-by: NDr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20191225023225.2785-4-linux@treblig.orgSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

Now the nct677* are gone, we can clean up some flags that are
always the same now and simplify some code.
Signed-off-by: NDr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20191225023225.2785-3-linux@treblig.orgSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

The nct6775 and nct6776 are supported by the separate nct6775.c driver,
so remove the code from the w83627ehf driver.
Suggested-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NDr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20191225023225.2785-2-linux@treblig.orgSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

MAX20796 is a dual-phase scalable integrated voltage regulator with
PMBus interface.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NChen 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: NGuenter Roeck <linux@roeck-us.net>

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: NGuenter Roeck <linux@roeck-us.net>

MAX31730 is a 3-Channel Remote Temperature Sensor.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

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: NGuenter Roeck <linux@roeck-us.net>

Convert the old hwmon_device_register code to
devm_hwmon_device_register_with_info.
Signed-off-by: NDr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20191124202030.45360-3-linux@treblig.orgSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

Add support for the UCD90320 chip and its expanded set of GPIO pins.
Signed-off-by: NJim Wright <wrightj@linux.vnet.ibm.com>
Link: https://lore.kernel.org/r/20191205232411.21492-3-wrightj@linux.vnet.ibm.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

Document the UCD90320 device tree binding.
Signed-off-by: NJim Wright <wrightj@linux.vnet.ibm.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20191205232411.21492-2-wrightj@linux.vnet.ibm.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

Add templates for intrusion%d_alarm and intrusion%d_beep.
Note, these start at 0.
Signed-off-by: NDr. David Alan Gilbert <linux@treblig.org>
Link: https://lore.kernel.org/r/20191124202030.45360-2-linux@treblig.orgSigned-off-by: NGuenter Roeck <linux@roeck-us.net>

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

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

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

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

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

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: NChristophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NLinus Torvalds <torvalds@linux-foundation.org>

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

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

Add pointer to datasheet and fix typo in printk message.
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Trivial cleanup removing empty line at wrong place.
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Apparently it is quite easy to forget ">" in quoting of email
address. This fixes it.
Signed-off-by: NPavel Machek <pavel@ucw.cz>

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: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

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: NAndy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

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: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>
[fixed comment]
Signed-off-by: NPavel Machek <pavel@ucw.cz>

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

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: NPeter Zijlstra <peterz@infradead.org>
Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>