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

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

2016-08-16T07:33:16+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-10T10:54:49+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: qup: Fix wrong value of index variable

2016-08-10T10:54:49+00:00

commit d4f56c7773483b8829e89cfc739b7a5a071f6da0 upstream.

index gets incremented during check to determine if the
messages can be transferred with dma. But not reset after
that, resulting in wrong start value in subsequent loop,
causing failure. Fix it.

Signed-off-by: Sricharan R 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

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

2016-04-22T13:31:54+00:00

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 
Cc: stable@kernel.org

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

2016-04-22T13:25:53+00:00

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 
Cc: stable@kernel.org
Fixes: ea8daa7b9784

i2c: ismt: Add Intel DNV PCI ID

2016-04-12T21:44:16+00:00

Intel DNV has the same iSMT SMBus host controller than Intel Avoton. Add
DNV PCI ID to the list of supported devices.

Signed-off-by: Mika Westerberg 
Acked-by: Andy Shevchenko 
Acked-by: Neil Horman 
Signed-off-by: Wolfram Sang

i2c: xlp9xx: add support for Broadcom Vulcan

2016-04-12T21:40:11+00:00

The Broadcom Vulcan ARM64 processor uses the same I2C controller
present on the Broadcom XLP9xx/5xx MIPS processor family.
Updated the Kconfig by adding ARCH_VULCAN option.

Signed-off-by: Tanmay Jagdale 
Signed-off-by: Wolfram Sang

i2c: rk3x: add support for rk3228

2016-04-12T21:34:44+00:00

Enable the I2C core for this SoC.

Signed-off-by: Yakir Yang 
Reviewed-by: Heiko Stuebner 
Acked-by: Rob Herring 
Signed-off-by: Wolfram Sang

i2c: jz4780: really prevent potential division by zero

2016-04-09T06:36:44+00:00

Make sure we avoid a division-by-zero OOPS in case clock-frequency is
set too low in DT. Add missing '\n' while we are here.

Signed-off-by: Wolfram Sang 
Acked-by: Axel Lin

Revert "i2c: jz4780: prevent potential division by zero"

2016-04-09T06:32:37+00:00

This reverts commit 34cf2acdafaa31a13821e45de5ee896adcd307b1. 'ret' is
not set when bailing out. Also, there is a better place to check for 0.

Reported-by: Axel Lin 
Signed-off-by: Wolfram Sang