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

i2c: efm32: fix a failure path in efm32_i2c_probe()

2016-08-20T16:09:19+00:00

commit 7dd91d52a813f99a95d20f539b777e9e6198b931 upstream.

There is the only failure path in efm32_i2c_probe(),
where clk_disable_unprepare() is missed.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Acked-by: Uwe Kleine-König 
Signed-off-by: Wolfram Sang 
Fixes: 1b5b23718b84 ("i2c: efm32: new bus driver")
Signed-off-by: Greg Kroah-Hartman

i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR

2016-08-16T07:30:48+00:00

commit a7ae81952cdab56a1277bd2f9ed7284c0f575120 upstream.

Many Intel systems the BIOS declares a SystemIO OpRegion below the SMBus
PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 900:

  Device (SBUS)
  {
      OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10)
      Field (SMBI, ByteAcc, NoLock, Preserve)
      {
          HSTS,   8,
          Offset (0x02),
          HCON,   8,
          HCOM,   8,
          TXSA,   8,
          DAT0,   8,
          DAT1,   8,
          HBDR,   8,
          PECR,   8,
          RXSA,   8,
          SDAT,   16
      }

There are also bunch of AML methods that that the BIOS can use to access
these fields. Most of the systems in question AML methods accessing the
SMBI OpRegion are never used.

Now, because of this SMBI OpRegion many systems fail to load the SMBus
driver with an error looking like one below:

  ACPI Warning: SystemIO range 0x0000000000003040-0x000000000000305F
       conflicts with OpRegion 0x0000000000003040-0x000000000000304F
       (\_SB.PCI0.SBUS.SMBI) (20160108/utaddress-255)
  ACPI: If an ACPI driver is available for this device, you should use
       it instead of the native driver

The reason is that this SMBI OpRegion conflicts with the PCI BAR used by
the SMBus driver.

It turns out that we can install a custom SystemIO address space handler
for the SMBus device to intercept all accesses through that OpRegion. This
allows us to share the PCI BAR with the AML code if it for some reason is
using it. We do not expect that this OpRegion handler will ever be called
but if it is we print a warning and prevent all access from the SMBus
driver itself.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=110041
Reported-by: Andy Lutomirski 
Reported-by: Pali Rohár 
Suggested-by: Rafael J. Wysocki 
Signed-off-by: Mika Westerberg 
Acked-by: Rafael J. Wysocki 
Reviewed-by: Jean Delvare 
Reviewed-by: Benjamin Tissoires 
Tested-by: Pali Rohár 
Tested-by: Jean Delvare 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: mux: reg: wrong condition checked for of_address_to_resource return value

2016-08-10T09:49:29+00:00

commit 22ebf00eb56fe77922de8138aa9af9996582c2b3 upstream.

of_address_to_resource return 0 on successful call but
devm_ioremap_resource is called only if it returns non-zero value

Signed-off-by: Lukasz Gemborowski 
Reviewed-by: Alexander Sverdlin 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

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