Merge branch 'i2c/for-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

Pull i2c updates from Wolfram Sang:

 - API for late atomic transfers (e.g. to shut down via PMIC). We have a
   seperate callback now which is called under clearly defined
   conditions. In-kernel users are converted, too.

 - new driver for the AMD PCIe MP2 I2C controller

 - large refactoring for at91 and bcm-iproc (both gain slave support due
   to this)

 - and a good share of various driver improvements anf fixes

* 'i2c/for-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (57 commits)
  dt-bindings: i2c: riic: document r7s9210 support
  i2c: imx-lpi2c: Use __maybe_unused instead of #if CONFIG_PM_SLEEP
  i2c-piix4: Add Hygon Dhyana SMBus support
  i2c: core: apply 'is_suspended' check for SMBus, too
  i2c: core: ratelimit 'transfer when suspended' errors
  i2c: iproc: Change driver to use 'BIT' macro
  i2c: riic: Add Runtime PM support
  i2c: mux: demux-pinctrl: use struct_size() in devm_kzalloc()
  i2c: mux: pca954x: allow management of device idle state via sysfs
  i2c: mux: pca9541: remove support for unused platform data
  i2c: mux: pca954x: remove support for unused platform data
  dt-bindings: i2c: i2c-mtk: add support for MT8516
  i2c: axxia: use auto cmd for last message
  i2c: gpio: flag atomic capability if possible
  i2c: algo: bit: add flag to whitelist atomic transfers
  i2c: stu300: use xfer_atomic callback to bail out early
  i2c: ocores: enable atomic xfers
  i2c: ocores: refactor setup for polling
  i2c: tegra-bpmp: convert to use new atomic callbacks
  i2c: omap: Add the master_xfer_atomic hook
  ...

1 files changed, 20 insertions, 0 deletions

diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-pca954x b/Documentation/ABI/testing/sysfs-bus-i2c-devices-pca954x
new file mode 100644
index 000000000000..0b0de8cd0d13
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-pca954x
@@ -0,0 +1,20 @@
+What:		/sys/bus/i2c/.../idle_state
+Date:		January 2019
+KernelVersion:	5.2
+Contact:	Robert Shearman <robert.shearman@att.com>
+Description:
+		Value that exists only for mux devices that can be
+		written to control the behaviour of the multiplexer on
+		idle. Possible values:
+		-2 - disconnect on idle, i.e. deselect the last used
+		     channel, which is useful when there is a device
+		     with an address that conflicts with another
+		     device on another mux on the same parent bus.
+		-1 - leave the mux as-is, which is the most optimal
+		     setting in terms of I2C operations and is the
+		     default mode.
+		0..<nchans> - set the mux to a predetermined channel,
+		     which is useful if there is one channel that is
+		     used almost always, and you want to reduce the
+		     latency for normal operations after rare
+		     transactions on other channels