linux-stable.git/drivers/i2c, branch linux-4.5.y

i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared

2016-05-04T21:49:07+00:00

commit 10ff4c5239a137abfc896ec73ef3d15a0f86a16a upstream.

The exynos5 I2C controller driver always prepares and enables a clock
before using it and then disables unprepares it when the clock is not
used anymore.

But this can cause a possible ABBA deadlock in some scenarios since a
driver that uses regmap to access its I2C registers, will first grab
the regmap lock and then the I2C xfer function will grab the prepare
lock when preparing the I2C clock. But since the clock driver also
uses regmap for I2C accesses, preparing a clock will first grab the
prepare lock and then the regmap lock when using the regmap API.

An example of this happens on the Exynos5422 Odroid XU4 board where a
s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers
share the same I2C regmap.

The possible deadlock is reported by the kernel lockdep:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(sec_core:428:(regmap)->lock);
                                lock(prepare_lock);
                                lock(sec_core:428:(regmap)->lock);
   lock(prepare_lock);

  *** DEADLOCK ***

Fix it by leaving the code prepared on probe and use {en,dis}able in
the I2C transfer function.

This patch is similar to commit 34e81ad5f0b6 ("i2c: s3c2410: fix ABBA
deadlock by keeping clock prepared") that fixes the same bug in other
driver for an I2C controller found in Samsung SoCs.

Reported-by: Anand Moon 
Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Anand Moon 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: cpm: Fix build break due to incompatible pointer types

2016-05-04T21:49:07+00:00

commit 609d5a1b2b35bb62b4b3750396e55453160c2a17 upstream.

Since commit ea8daa7b9784 ("kbuild: Add option to turn incompatible
pointer check into error"), assignments from an incompatible pointer
types have become a hard error, eg:

  drivers/i2c/busses/i2c-cpm.c:545:91: error: passing argument 3 of
  'dma_alloc_coherent' from incompatible pointer type

Fix the build break by converting txdma & rxdma to dma_addr_t.

Signed-off-by: Michael Ellerman 
Signed-off-by: Wolfram Sang 
Fixes: ea8daa7b9784
Signed-off-by: Greg Kroah-Hartman

i2c: brcmstb: allocate correct amount of memory for regmap

2016-03-01T18:16:45+00:00

We want the size of the struct, not of a pointer to it. To be future
proof, just dereference the pointer to get the desired type.

Fixes: dd1aa2524bc5 ("i2c: brcmstb: Add Broadcom settop SoC i2c controller driver")
Acked-by: Gregory Fong 
Acked-by: Florian Fainelli 
Reviewed-by: Kamal Dasu 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org

i2c: i801: Adding Intel Lewisburg support for iTCO

2016-02-18T12:18:48+00:00

Starting from Intel Sunrisepoint (Skylake PCH) the iTCO watchdog
resources have been moved to reside under the i801 SMBus host
controller whereas previously they were under the LPC device.

This patch adds Intel lewisburg SMBus support for iTCO device.
It allows to load watchdog dynamically when the hardware is
present.

Fixes: cdc5a3110e7c ("i2c: i801: add Intel Lewisburg device IDs")
Reviewed-by: Jean Delvare 
Signed-off-by: Alexandra Yates 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org

i2c: uniphier: fix typos in error messages

2016-02-12T19:23:37+00:00

Signed-off-by: Masahiro Yamada 
Signed-off-by: Wolfram Sang

i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit

2016-02-12T18:42:31+00:00

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Signed-off-by: Tony Lindgren 
Acked-by: Ulf Hansson 
Signed-off-by: Wolfram Sang

i2c: piix4: don't regress on bus names

2016-01-29T10:13:52+00:00

The I2C bus names are supposed to be stable as they can be used by
userspace to uniquely identify a specific I2C bus. So restore the
original names for all legacy (pre-SB800) devices.

For SB800 devices and later, improve the names. "SDA" refers to the
serial data pin of each SMBus port, it's an implementation detail the
user doesn't need to know. Use "port" instead, which is easier to
understand.

Signed-off-by: Jean Delvare 
Reviewed-by: Mika Westerberg 
Tested-by: Christian Fetzer 
Signed-off-by: Wolfram Sang

i2c: designware-pci: use IRQF_COND_SUSPEND flag

2016-01-26T06:00:27+00:00

This is effectively reapplies the commit b0898fdaffb2 ("i2c: designware-pci: use
IRQF_COND_SUSPEND flag") after the commit d80d134182ba ("i2c: designware: Move
common probe code into i2c_dw_probe()"). Original message as follows.

The mentioned flag fixes a warning on Intel Edison board since one of the I2C
controller shares IRQ line with watchdog timer.

Fixes: d80d134182ba (i2c: designware: Move common probe code into i2c_dw_probe())
Signed-off-by: Andy Shevchenko 
Acked-by: Jarkko Nikula 
Signed-off-by: Wolfram Sang

i2c: piix4: Fully initialize SB800 before it is registered

2016-01-26T05:46:33+00:00

This closes a race window where I2C device drivers attempt to access
I2C buses which aren't fully initialized yet.

Signed-off-by: Jean Delvare 
Tested-by: Christian Fetzer 
Signed-off-by: Wolfram Sang

i2c: piix4: Fix SB800 locking

2016-01-26T05:46:26+00:00

We need a single mutex for all 4 shared SMBus ports on the SB800. A
per-port mutex doesn't protect us from concurrent access.

In theory the mutex should be per PCI device, however in practice we
know that there's only ever a single instance of the device in a given
system so we can use a global.

Also take the mutex during initialization, as first port may be already
in use when second port is initialized.

Signed-off-by: Jean Delvare 
Tested-by: Christian Fetzer 
Reviewed-by: Mika Westerberg 
[wsa: made mutex static]
Signed-off-by: Wolfram Sang