linux-stable.git/drivers/i2c, branch v4.4.16

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

2016-05-04T21:48:47+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:48:47+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-09T23:34:56+00:00

commit 7314d22a2f5bd40468d57768be368c3d9b4bd726 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

i2c: i801: Adding Intel Lewisburg support for iTCO

2016-03-03T23:07:28+00:00

commit 1a1503c5396eb7f2edf4b8ef6067853014478c0c upstream.

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 
Signed-off-by: Greg Kroah-Hartman

i2c: rcar: disable runtime PM correctly in slave mode

2015-12-19T11:00:37+00:00

When we also are I2C slave, we need to disable runtime PM because the
address detection mechanism needs to be active all the time. However, we
can reenable runtime PM once the slave instance was unregistered. So,
use pm_runtime_get_sync/put to achieve this, since it has proper
refcounting. pm_runtime_allow/forbid is like a global knob controllable
from userspace which is unsuitable here.

Signed-off-by: Wolfram Sang 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org

i2c: designware: Keep pm_runtime_enable/_disable calls in sync

2015-12-12T17:04:57+00:00

On an hardware shared I2C bus (certain Intel Baytrail SoC platforms) the
runtime PM disable depth keeps increasing over repeated modprobe/rmmod
cycle because pm_runtime_disable() is called without checking should it
be disabled already because of bus sharing.

This hasn't made any other harm than dev->power.disable_depth keeps
increasing but keep it sync by calling pm_runtime_disable() only when
runtime PM is not disabled.

Reported-by: Wolfram Sang 
Signed-off-by: Jarkko Nikula 
Signed-off-by: Wolfram Sang

i2c: designware: fix IO timeout issue for AMD controller

2015-12-12T17:00:16+00:00

Because of some hardware limitation, AMD I2C controller can't
trigger pending interrupt if interrupt status has been changed
after clearing interrupt status bits. Then, I2C will lost
interrupt and IO timeout.

According to hardware design, this patch implements a workaround
to disable i2c controller interrupt and re-enable i2c interrupt
before exiting ISR.

To reduce the performance impacts on other vendors, use unlikely
function to check flag in ISR.

Signed-off-by: Xiangliang Yu 
Acked-by: Jarkko Nikula 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org

i2c: imx: init bus recovery info before adding i2c adapter

2015-12-09T10:15:41+00:00

During driver probe, i2c_imx_init_recovery_info() must come before
i2c_add_numbered_adapter(), because the get/set_scl() functions
are assigned in i2c_register_adapter() under the conditon that bus
recover_info are initialized. Otherwise, get/set_scl() function
pointers never get assigned.

In such case, when i2c_generic_gpio_recovery() is used for bus recovery,
there will be kernel crash because bri->set_scl is NULL.

The solution to this bug is moving i2c_imx_init_recovery_info() before
i2c_register_adapter().

Signed-off-by: Gao Pan 
Signed-off-by: Fugang Duan 
Acked-by: Uwe Kleine-König 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org

i2c: do not use 0x in front of %pa

2015-12-01T01:01:27+00:00

Signed-off-by: Dmitry V. Krivenok 
Signed-off-by: Wolfram Sang

i2c: davinci: Increase module clock frequency

2015-11-30T14:55:07+00:00

I2C controller used in Keystone SoC has an undocumented peculiarity which
results in SDA-SCL margins being dependent on module clock. Driving high
capacity bus near its limits can result in STOP condition sometimes being
understood as REPEATED-START by slaves (or NACK instead of ACK, etc...).
Driving the module with higher clocks increases the margin between SDA and SCL
transitions, making the operations with higher bus rates more robust. Therefore,
target the module clock to 12MHz instead of 7MHz, still staying within
the specification limits.

Before the change STOP timing looked like this on 400kHz:

SDA   ----------+          +----
                 \        /
                  \      /
                   +----+
                       (1)
SCL   --+          +------------
         \        /
          \      /
           +----+
               (2)

While only point (1) signals STOP, point (2) could be incorrectly recognized as
repeated-START (almost no margin between SDA and SCL transitions).

After the change there is at least 600ns margin measured between SCL fall and
SDA fall during STOP generation:

SDA   ------+          +----
             \        /
              \      /
               +----+

SCL   --+          +--------
         \        /
          \      /
           +----+
           ->|    |<- 600ns
                ->|   |<- tSUSTO

So called tSUSTO (setup time for STOP condition) is still slightly higher than
600ns, so no problem here.

Signed-off-by: Alexander Sverdlin 
Acked-by: Santosh Shilimkar 
Signed-off-by: Wolfram Sang