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

i2c: i2c-mux-pca954x: fix deselect enabling for device-tree

2016-11-26T08:56:55+00:00

commit ad092de60f865c1ad94221bd06d381ecea446cc8 upstream.

Deselect functionality can be ignored for device-trees with
"i2c-mux-idle-disconnect" entries if no platform_data is available.
By enabling the deselect functionality outside the platform_data
block the logic works as it did in previous kernels.

Fixes: 7fcac9807175 ("i2c: i2c-mux-pca954x: convert to use an explicit i2c mux core")
Signed-off-by: Alex Hemme 
Signed-off-by: Ziyang Wu 
[touched up a few minor issues /peda]
Signed-off-by: Peter Rosin 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: mux: fix up dependencies

2016-11-26T08:56:54+00:00

commit 93d710a65ef02fb7fd48ae207e78f460bd7a6089 upstream.

We get the following build error from UM Linux after adding
an entry to drivers/iio/gyro/Kconfig that issues "select I2C_MUX":

ERROR: "devm_ioremap_resource"
   [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
ERROR: "of_address_to_resource"
   [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!

It appears that the I2C mux core code depends on HAS_IOMEM
for historical reasons, while CONFIG_I2C_MUX_REG does *not*
have a direct dependency on HAS_IOMEM.

This creates a situation where a allyesconfig or allmodconfig
for UM Linux will select I2C_MUX, and will implicitly enable
I2C_MUX_REG as well, and the compilation will fail for the
register driver.

Fix this up by making I2C_MUX_REG depend on HAS_IOMEM and
removing the dependency from I2C_MUX.

Reported-by: kbuild test robot 
Reported-by: Jonathan Cameron 
Signed-off-by: Linus Walleij 
Acked-by: Jonathan Cameron 
Acked-by: Peter Rosin 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: mark device nodes only in case of successful instantiation

2016-11-10T15:38:56+00:00

commit 6a676fb69dcbf3310b9e462c1db66c8e7f6ead38 upstream.

Instantiated I2C device nodes are marked with OF_POPULATE. This was
introduced in 4f001fd30145a6. On unloading, loaded device nodes will of
course be unmarked. The problem are nodes that fail during
initialisation: If a node fails, it won't be unloaded and hence not be
unmarked.

If a I2C driver module is unloaded and reloaded, it will skip nodes that
failed before.

Skip device nodes that are already populated and mark them only in case
of success.

Fixes: 4f001fd30145a6 ("i2c: Mark instantiated device nodes with OF_POPULATE")
Signed-off-by: Ralf Ramsauer 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Pantelis Antoniou 
[wsa: use 14-digit commit sha]
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: core: fix NULL pointer dereference under race condition

2016-11-10T15:38:45+00:00

commit 147b36d5b70c083cc76770c47d60b347e8eaf231 upstream.

Race condition between registering an I2C device driver and
deregistering an I2C adapter device which is assumed to manage that
I2C device may lead to a NULL pointer dereference due to the
uninitialized list head of driver clients.

The root cause of the issue is that the I2C bus may know about the
registered device driver and thus it is matched by bus_for_each_drv(),
but the list of clients is not initialized and commonly it is NULL,
because I2C device drivers define struct i2c_driver as static and
clients field is expected to be initialized by I2C core:

  i2c_register_driver()             i2c_del_adapter()
    driver_register()                 ...
      bus_add_driver()                ...
        ...                           bus_for_each_drv(..., __process_removed_adapter)
      ...                               i2c_do_del_adapter()
    ...                                   list_for_each_entry_safe(..., &driver->clients, ...)
    INIT_LIST_HEAD(&driver->clients);

To solve the problem it is sufficient to do clients list head
initialization before calling driver_register().

The problem was found while using an I2C device driver with a sluggish
registration routine on a bus provided by a physically detachable I2C
master controller, but practically the oops may be reproduced under
the race between arbitraty I2C device driver registration and managing
I2C bus device removal e.g. by unbinding the latter over sysfs:

% echo 21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind
  Unable to handle kernel NULL pointer dereference at virtual address 00000000
  Internal error: Oops: 17 [#1] SMP ARM
  CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61
  Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
  task: e5ada400 task.stack: e4936000
  PC is at i2c_do_del_adapter+0x20/0xcc
  LR is at __process_removed_adapter+0x14/0x1c
  Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
  Control: 10c5387d  Table: 35bd004a  DAC: 00000051
  Process sh (pid: 533, stack limit = 0xe4936210)
  Stack: (0xe4937d28 to 0xe4938000)
  Backtrace:
  [] (i2c_do_del_adapter) from [] (__process_removed_adapter+0x14/0x1c)
  [] (__process_removed_adapter) from [] (bus_for_each_drv+0x6c/0xa0)
  [] (bus_for_each_drv) from [] (i2c_del_adapter+0xbc/0x284)
  [] (i2c_del_adapter) from [] (i2c_imx_remove+0x44/0x164 [i2c_imx])
  [] (i2c_imx_remove [i2c_imx]) from [] (platform_drv_remove+0x2c/0x44)
  [] (platform_drv_remove) from [] (__device_release_driver+0x90/0x12c)
  [] (__device_release_driver) from [] (device_release_driver+0x28/0x34)
  [] (device_release_driver) from [] (unbind_store+0x80/0x104)
  [] (unbind_store) from [] (drv_attr_store+0x28/0x34)
  [] (drv_attr_store) from [] (sysfs_kf_write+0x50/0x54)
  [] (sysfs_kf_write) from [] (kernfs_fop_write+0x100/0x214)
  [] (kernfs_fop_write) from [] (__vfs_write+0x34/0x120)
  [] (__vfs_write) from [] (vfs_write+0xa8/0x170)
  [] (vfs_write) from [] (SyS_write+0x4c/0xa8)
  [] (SyS_write) from [] (ret_fast_syscall+0x0/0x1c)

Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: xgene: Avoid dma_buffer overrun

2016-11-10T15:38:44+00:00

commit 603616017c35f4d0fbdbcace72adf9bf949c4a65 upstream.

SMBus block command uses the first byte of buffer for the data length.
The dma_buffer should be increased by 1 to avoid the overrun issue.

Reported-by: Phil Endecott 
Signed-off-by: Hoan Tran 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: rk3x: Give the tuning value 0 during rk3x_i2c_v0_calc_timings

2016-11-10T15:38:44+00:00

commit 399c168ab5ab5e12ed55b6c91d61c24eb84c9164 upstream.

We found a bug that i2c transfer sometimes failed on 3066a board with
stabel-4.8, the con register would be updated by uninitialized tuning
value, it made the i2c transfer failed.

So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.

Signed-off-by: David Wu 
Tested-by: Andy Yan 
Reviewed-by: Douglas Anderson 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

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

2016-09-22T18:11:14+00:00

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

i2c: mux: pca954x: retry updating the mux selection on failure

2016-09-21T21:10:21+00:00

The cached value of the last selected channel prevents retries on the
next call, even on failure to update the selected channel. Fix that.

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

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

2016-09-21T16:07:51+00:00

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

i2c: rk3x: Restore clock settings at resume time

2016-09-08T20:50:33+00:00

Depending on a number of factors including:
- Which exact Rockchip SoC we're working with
- How deep we suspend
- Which i2c port we're on

We might lose the state of the i2c registers at suspend time.
Specifically we've found that on rk3399 the i2c ports that are not in
the PMU power domain lose their state with the current suspend depth
configured by ARM Tursted Firmware.

Note that there are very few actual i2c registers that aren't configured
per transfer anyway so all we actually need to re-configure are the
clock config registers.  We'll just add a call to rk3x_i2c_adapt_div()
at resume time and be done with it.

NOTE: On rk3399 on ports whose power was lost, I put printouts in at
resume time.  I saw things like:
  before: con=0x00010300, div=0x00060006
  after:  con=0x00010200, div=0x00180025

Signed-off-by: Douglas Anderson 
Reviewed-by: David Wu 
Tested-by: David Wu 
[wsa: removed duplicate const]
Signed-off-by: Wolfram Sang