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

i2c: imx: Use correct function to write to register

2017-06-22T08:52:02+00:00

The i2c-imx driver incorrectly uses readb()/writeb() to read and
write to the appropriate registers when performing a repeated start.
The appropriate imx_i2c_read_reg()/imx_i2c_write_reg() functions
should be used instead. Performing a repeated start results in
a kernel panic. The platform is imx.

Signed-off-by: Michail G Etairidis 
Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
Fixes: 054b62d9f25c ("i2c: imx: fix the i2c bus hang issue when do repeat restart")
Acked-by: Fugang Duan 
Acked-by: Uwe Kleine-König 
Signed-off-by: Wolfram Sang

i2c: ismt: fix wrong device address when unmap the data buffer

2017-06-15T14:07:03+00:00

Fix the following kernel bug:

kernel BUG at drivers/iommu/intel-iommu.c:3260!
invalid opcode: 0000 [#5] PREEMPT SMP
Hardware name: Intel Corp. Harcuvar/Server, BIOS HAVLCRB0.X64.0013.D39.1608311820 08/31/2016
task: ffff880175389950 ti: ffff880176bec000 task.ti: ffff880176bec000
RIP: 0010:[]  [] intel_unmap+0x25b/0x260
RSP: 0018:ffff880176bef5e8  EFLAGS: 00010296
RAX: 0000000000000024 RBX: ffff8800773c7c88 RCX: 000000000000ce04
RDX: 0000000080000000 RSI: 0000000000000000 RDI: 0000000000000009
RBP: ffff880176bef638 R08: 0000000000000010 R09: 0000000000000004
R10: ffff880175389c78 R11: 0000000000000a4f R12: ffff8800773c7868
R13: 00000000ffffac88 R14: ffff8800773c7818 R15: 0000000000000001
FS:  00007fef21258700(0000) GS:ffff88017b5c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000066d6d8 CR3: 000000007118c000 CR4: 00000000003406e0
Stack:
 00000000ffffac88 ffffffff8199867f ffff880176bef5f8 ffff880100000030
 ffff880176bef668 ffff8800773c7c88 ffff880178288098 ffff8800772c0010
 ffff8800773c7818 0000000000000001 ffff880176bef648 ffffffff8150a86e
Call Trace:
 [] ? printk+0x46/0x48
 [] intel_unmap_page+0xe/0x10
 [] ismt_access+0x27b/0x8fa [i2c_ismt]
 [] ? __pm_runtime_suspend+0xa0/0xa0
 [] ? pm_suspend_timer_fn+0x80/0x80
 [] ? __pm_runtime_suspend+0xa0/0xa0
 [] ? pm_suspend_timer_fn+0x80/0x80
 [] ? pci_bus_read_dev_vendor_id+0xf0/0xf0
 [] i2c_smbus_xfer+0xec/0x4b0
 [] ? vprintk_emit+0x345/0x530
 [] i2cdev_ioctl_smbus+0x12b/0x240 [i2c_dev]
 [] ? vprintk_default+0x29/0x40
 [] i2cdev_ioctl+0x63/0x1ec [i2c_dev]
 [] do_vfs_ioctl+0x328/0x5d0
 [] ? vfs_write+0x11c/0x190
 [] ? rt_up_read+0x19/0x20
 [] SyS_ioctl+0x81/0xa0
 [] system_call_fastpath+0x16/0x6e

This happen When run "i2cdetect -y 0" detect SMBus iSMT adapter.

After finished I2C block read/write, when unmap the data buffer,
a wrong device address was pass to dma_unmap_single().

To fix this, give dma_unmap_single() the "dev" parameter, just like
what dma_map_single() does, then unmap can find the right devices.

Fixes: 13f35ac14cd0 ("i2c: Adding support for Intel iSMT SMBus 2.0 host controller")
Signed-off-by: Liwei Song 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Wolfram Sang

i2c: rcar: use correct length when unmapping DMA

2017-06-15T13:51:44+00:00

Because we need to transfer some bytes with PIO, the msg length is not
the length of the DMA buffer. Use the correct value which we used when
doing the mapping.

Fixes: 73e8b0528346e8 ("i2c: rcar: add DMA support")
Signed-off-by: Wolfram Sang 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Niklas Söderlund 
Signed-off-by: Wolfram Sang

i2c: designware: Fix bogus sda_hold_time due to uninitialized vars

2017-05-22T08:35:51+00:00

We need to initializes those variables to 0 for platforms that do not
provide ACPI parameters. Otherwise, we set sda_hold_time to random
values, breaking e.g. Galileo and IOT2000 boards.

Fixes: 9d6408433019 ("i2c: designware: don't infer timings described by ACPI from clock rate")
Signed-off-by: Jan Kiszka 
Reviewed-by: Ard Biesheuvel 
Acked-by: Jarkko Nikula 
Signed-off-by: Wolfram Sang

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

2017-05-22T08:33:42+00:00

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

i2c: designware: don't infer timings described by ACPI from clock rate

2017-05-19T12:36:24+00:00

Commit bd698d24b1b57 ("i2c: designware: Get selected speed mode
sda-hold-time via ACPI") updated the logic that reads the timing
parameters for various I2C bus rates from the DSDT, to only read
the timing parameters for the currently selected mode.

This causes a WARN_ON() splat on platforms that legally omit the clock
frequency from the ACPI description, because in the new situation, the
core I2C designware driver still accesses the fields in the driver
struct that we no longer populate, and proceeds to calculate them from
the clock frequency. Since the clock frequency is unspecified, the
driver complains loudly using a WARN_ON().

So revert back to the old situation, where the struct fields for all
timings are populated, but retain the new logic which chooses the SDA
hold time from the timing mode that is currently in use.

Fixes: bd698d24b1b57 ("i2c: designware: Get selected speed mode ...")
Signed-off-by: Ard Biesheuvel 
Reported-by: Lorenzo Pieralisi 
Acked-by: Jarkko Nikula 
Signed-off-by: Wolfram Sang

i2c: xgene: Set ACPI_COMPANION_I2C

2017-05-17T07:21:06+00:00

With ACPI, i2c-core requires ACPI companion to be set in order for it
to create slave device.
This patch sets the ACPI companion accordingly.

Signed-off-by: Tin Huynh 
Signed-off-by: Wolfram Sang

i2c: mv64xxx: don't override deferred probing when getting irq

2017-05-16T21:19:00+00:00

There is no reason to use platform_get_irq() for non-DT probing and
irq_of_parse_and_map() for DT probing. Indeed, platform_get_irq()
works fine for both.

In addition, using platform_get_irq() properly returns -EPROBE_DEFER
when the interrupt controller is not yet available, so instead of
inventing our own error code (-ENXIO), return the one provided by
platform_get_irq().

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Wolfram Sang

i2c: mux: only print failure message on error

2017-05-15T16:49:11+00:00

As is, a failure message is printed unconditionally, which is confusing.
And noisy.

Fixes: 8d4d159f25a7 ("i2c: mux: provide more info on failure in i2c_mux_add_adapter")
Signed-off-by: Peter Rosin

i2c: mux: reg: rename label to indicate what it does

2017-05-15T16:49:10+00:00

That maintains sanity if it is ever called from some other spot, and
also makes the label names coherent.

Signed-off-by: Peter Rosin