linux-toradex.git/drivers/i2c, branch v4.4.23

i2c: qup: skip qup_i2c_suspend if the device is already runtime suspended

2016-09-30T08:18:38+00:00

commit 331dcf421c34d227784d07943eb01e4023a42b0a upstream.

If the i2c device is already runtime suspended, if qup_i2c_suspend is
executed during suspend-to-idle or suspend-to-ram it will result in the
following splat:

WARNING: CPU: 3 PID: 1593 at drivers/clk/clk.c:476 clk_core_unprepare+0x80/0x90
Modules linked in:

CPU: 3 PID: 1593 Comm: bash Tainted: G        W       4.8.0-rc3 #14
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
PC is at clk_core_unprepare+0x80/0x90
LR is at clk_unprepare+0x28/0x40
pc : [] lr : [] pstate: 60000145
Call trace:
 clk_core_unprepare+0x80/0x90
 qup_i2c_disable_clocks+0x2c/0x68
 qup_i2c_suspend+0x10/0x20
 platform_pm_suspend+0x24/0x68
 ...

This patch fixes the issue by executing qup_i2c_pm_suspend_runtime
conditionally in qup_i2c_suspend.

Signed-off-by: Sudeep Holla 
Reviewed-by: Andy Gross 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c-eg20t: fix race between i2c init and interrupt enable

2016-09-30T08:18:38+00:00

commit 371a015344b6e270e7e3632107d9554ec6d27a6b upstream.

the eg20t driver call request_irq() function before the pch_base_address,
base address of i2c controller's register, is assigned an effective value.

there is one possible scenario that an interrupt which isn't inside eg20t
arrives immediately after request_irq() is executed when i2c controller
shares an interrupt number with others. since the interrupt handler
pch_i2c_handler() has already active as shared action, it will be called
and read its own register to determine if this interrupt is from itself.

At that moment, since base address of i2c registers is not remapped
in kernel space yet,so the INT handler will access an illegal address
and then a error occurs.

Signed-off-by: Yadi.hu 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: cros-ec-tunnel: Fix usage of cros_ec_cmd_xfer()

2016-09-07T06:32:43+00:00

commit 4d01d88019261d05ec3bff5f1a6013393faa3b9e upstream.

cros_ec_cmd_xfer returns success status if the command transport
completes successfully, but the execution result is incorrectly ignored.
In many cases, the execution result is assumed to be successful, leading
to ignored errors and operating on uninitialized data.

We've recently introduced the cros_ec_cmd_xfer_status() helper to avoid these
problems. Let's use it.

[Regarding the 'Fixes' tag; there is significant refactoring since the driver's
introduction, but the underlying logical error exists throughout I believe]

Fixes: 9d230c9e4f4e ("i2c: ChromeOS EC tunnel driver")
Signed-off-by: Brian Norris 
Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Guenter Roeck 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

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