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

i2c: i2c-tiny-usb: fix buffer not being DMA capable

2017-06-08T10:12:47+00:00

[ Upstream commit 5165da5923d6c7df6f2927b0113b2e4d9288661e ]

Since v4.9 i2c-tiny-usb generates the below call trace
and longer works, since it can't communicate with the
USB device. The reason is, that since v4.9 the USB
stack checks, that the buffer it should transfer is DMA
capable. This was a requirement since v2.2 days, but it
usually worked nevertheless.

[   17.504959] ------------[ cut here ]------------
[   17.505488] WARNING: CPU: 0 PID: 93 at drivers/usb/core/hcd.c:1587 usb_hcd_map_urb_for_dma+0x37c/0x570
[   17.506545] transfer buffer not dma capable
[   17.507022] Modules linked in:
[   17.507370] CPU: 0 PID: 93 Comm: i2cdetect Not tainted 4.11.0-rc8+ #10
[   17.508103] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[   17.509039] Call Trace:
[   17.509320]  ? dump_stack+0x5c/0x78
[   17.509714]  ? __warn+0xbe/0xe0
[   17.510073]  ? warn_slowpath_fmt+0x5a/0x80
[   17.510532]  ? nommu_map_sg+0xb0/0xb0
[   17.510949]  ? usb_hcd_map_urb_for_dma+0x37c/0x570
[   17.511482]  ? usb_hcd_submit_urb+0x336/0xab0
[   17.511976]  ? wait_for_completion_timeout+0x12f/0x1a0
[   17.512549]  ? wait_for_completion_timeout+0x65/0x1a0
[   17.513125]  ? usb_start_wait_urb+0x65/0x160
[   17.513604]  ? usb_control_msg+0xdc/0x130
[   17.514061]  ? usb_xfer+0xa4/0x2a0
[   17.514445]  ? __i2c_transfer+0x108/0x3c0
[   17.514899]  ? i2c_transfer+0x57/0xb0
[   17.515310]  ? i2c_smbus_xfer_emulated+0x12f/0x590
[   17.515851]  ? _raw_spin_unlock_irqrestore+0x11/0x20
[   17.516408]  ? i2c_smbus_xfer+0x125/0x330
[   17.516876]  ? i2c_smbus_xfer+0x125/0x330
[   17.517329]  ? i2cdev_ioctl_smbus+0x1c1/0x2b0
[   17.517824]  ? i2cdev_ioctl+0x75/0x1c0
[   17.518248]  ? do_vfs_ioctl+0x9f/0x600
[   17.518671]  ? vfs_write+0x144/0x190
[   17.519078]  ? SyS_ioctl+0x74/0x80
[   17.519463]  ? entry_SYSCALL_64_fastpath+0x1e/0xad
[   17.519959] ---[ end trace d047c04982f5ac50 ]---

Cc: 
Signed-off-by: Sebastian Reichel 
Reviewed-by: Greg Kroah-Hartman 
Acked-by: Till Harbaum 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

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

2016-07-11T03:07:10+00:00

[ Upstream commit 10ff4c5239a137abfc896ec73ef3d15a0f86a16a ]

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
Signed-off-by: Sasha Levin

i2c: mv64xxx: really allow I2C offloading

2015-11-09T22:33:37+00:00

commit 0729a04977d497cf66234fd7f900ddcec3ef1c52 upstream.

Commit 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix
several problems") completely reworked the offload support, but left a
debugging-related "return false" at the beginning of the
mv64xxx_i2c_can_offload() function. This has the unfortunate consequence
that offloading is in fact never used, which wasn't really the
intention.

This commit fixes that problem by removing the bogus "return false".

Fixes: 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix several problems")
Signed-off-by: Hezi Shahmoon 
[Thomas: reworked commit log and title.]
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: designware-platdrv: enable RuntimePM before registering to the core

2015-10-27T00:51:56+00:00

commit 36d48fb5766aee9717e429f772046696b215282d upstream.

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail.

Signed-off-by: Wolfram Sang 
Signed-off-by: Wolfram Sang 
Acked-by: Mika Westerberg 
Signed-off-by: Greg Kroah-Hartman

i2c: designware: Do not use parameters from ACPI on Dell Inspiron 7348

2015-10-27T00:51:56+00:00

commit 56d4b8a24cef5d66f0d10ac778a520d3c2c68a48 upstream.

ACPI SSCN/FMCN methods were originally added because then the platform can
provide the most accurate HCNT/LCNT values to the driver. However, this
seems not to be true for Dell Inspiron 7348 where using these causes the
touchpad to fail in boot:

  i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
  i2c_designware INT3433:00: i2c_dw_handle_tx_abort: lost arbitration
  i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
  i2c_designware INT3433:00: controller timed out

The values received from ACPI are (in fast mode):

  HCNT: 72
  LCNT: 160

this translates to following timings (input clock is 100MHz on Broadwell):

  tHIGH: 720 ns (spec min 600 ns)
  tLOW: 1600 ns (spec min 1300 ns)
  Bus period: 2920 ns (assuming 300 ns tf and tr)
  Bus speed: 342.5 kHz

Both tHIGH and tLOW are within the I2C specification.

The calculated values when ACPI parameters are not used are (in fast mode):

  HCNT: 87
  LCNT: 159

which translates to:

  tHIGH: 870 ns (spec min 600 ns)
  tLOW: 1590 ns (spec min 1300 ns)
  Bus period 3060 ns (assuming 300 ns tf and tr)
  Bus speed 326.8 kHz

These values are also within the I2C specification.

Since both ACPI and calculated values meet the I2C specification timing
requirements it is hard to say why the touchpad does not function properly
with the ACPI values except that the bus speed is higher in this case (but
still well below the max 400kHz).

Solve this by adding DMI quirk to the driver that disables using ACPI
parameters on this particulare machine.

Reported-by: Pavel Roskin 
Signed-off-by: Mika Westerberg 
Tested-by: Pavel Roskin 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: s3c2410: enable RuntimePM before registering to the core

2015-10-27T00:51:55+00:00

commit eadd709f5d2e8aebb1b7bf49460e97a68d81a9b0 upstream.

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail. While here, move drvdata, too.

Signed-off-by: Wolfram Sang 
Tested-by: Krzysztof Kozlowski 
Acked-by: Kukjin Kim 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: rcar: enable RuntimePM before registering to the core

2015-10-27T00:51:55+00:00

commit 4f7effddf4549d57114289f273710f077c4c330a upstream.

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail. While here, move drvdata, too.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Wolfram Sang 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: use parent adapter quirks in mux

2015-08-03T16:29:01+00:00

commit dc362d50ba94eaf2b1f11eecd81eb1d040d2d6e6 upstream.

Inherit parent adapter quirks in MUX in case the devices on the multiplexed
buses are interested in the adapter limitations.

Signed-off-by: Łukasz Gemborowski 
Signed-off-by: Alexander Sverdlin 
Signed-off-by: Wolfram Sang 
Fixes: b7f625840267b1 ("i2c: add quirk checks to core")
Signed-off-by: Greg Kroah-Hartman

i2c: mux: pca954x: Use __i2c_transfer because of quirks

2015-08-03T16:29:01+00:00

commit 0a8237ae319ab5988d40a7a9b33d68846aae34b4 upstream.

pca9541 and pca954x are calling master_xfer() of the parent adapter directly
thus bypassing the quirks checks of the adapter. Use __i2c_transfer() instead.

Signed-off-by: Alexander Sverdlin 
Tested-by: Łukasz Gemborowski 
Acked-by: Laurent Pinchart 
Reviewed-by: Jisheng Zhang 
Signed-off-by: Wolfram Sang 
Fixes: b7f625840267b1 ("i2c: add quirk checks to core")
Signed-off-by: Greg Kroah-Hartman

i2c: mux: Use __i2c_transfer() instead of calling parent's master_xfer()

2015-08-03T16:29:01+00:00

commit e766f338a74200b8104b1165776b19f56e252834 upstream.

Newly introduced quirks infrastructure doesn't work for the devices behind
MUXes because MUX's master_xfer() calls parent's master_xfer() directly
without checking the quirks. Instead of duplicating check code in MUX just
call __i2c_transfer() instead. This has a side effect on tracing (messages
will appear on both MUX bus and parent bus), but maybe that's not bad at
the end.

Signed-off-by: Alexander Sverdlin 
Tested-by: Łukasz Gemborowski 
Signed-off-by: Wolfram Sang 
Fixes: b7f625840267b1 ("i2c: add quirk checks to core")
Signed-off-by: Greg Kroah-Hartman