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

i2c: ismt: Return EMSGSIZE for block reads with bogus length

2017-09-07T06:35:39+00:00

commit ba201c4f5ebe13d7819081756378777d8153f23e upstream.

Compare the number of bytes actually seen on the wire to the byte
count field returned by the slave device.

Previously we just overwrote the byte count returned by the slave
with the real byte count and let the caller figure out if the
message was sane.

Signed-off-by: Stephen Douthit 
Tested-by: Dan Priamo 
Acked-by: Neil Horman 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: ismt: Don't duplicate the receive length for block reads

2017-09-07T06:35:39+00:00

commit b6c159a9cb69c2cf0bf59d4e12c3a2da77e4d994 upstream.

According to Table 15-14 of the C2000 EDS (Intel doc #510524) the
rx data pointed to by the descriptor dptr contains the byte count.

desc->rxbytes reports all bytes read on the wire, including the
"byte count" byte.  So if a device sends 4 bytes in response to a
block read, on the wire and in the DMA buffer we see:

count data1 data2 data3 data4
 0x04  0xde  0xad  0xbe  0xef

That's what we want to return in data->block to the next level.

Instead we were actually prefixing that with desc->rxbytes:

bad
count count data1 data2 data3 data4
 0x05  0x04  0xde  0xad  0xbe  0xef

This was discovered while developing a BMC solution relying on the
ipmi_ssif.c driver which was trying to interpret the bogus length
field as part of the IPMI response.

Signed-off-by: Stephen Douthit 
Tested-by: Dan Priamo 
Acked-by: Neil Horman 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: designware: Fix system suspend

2017-08-30T08:21:46+00:00

commit a23318feeff662c8d25d21623daebdd2e55ec221 upstream.

The commit 8503ff166504 ("i2c: designware: Avoid unnecessary resuming
during system suspend"), may suggest to the PM core to try out the so
called direct_complete path for system sleep. In this path, the PM core
treats a runtime suspended device as it's already in a proper low power
state for system sleep, which makes it skip calling the system sleep
callbacks for the device, except for the ->prepare() and the ->complete()
callbacks.

However, the PM core may unset the direct_complete flag for a parent
device, in case its child device are being system suspended before. In this
scenario, the PM core invokes the system sleep callbacks, no matter if the
device is runtime suspended or not.

Particularly in cases of an existing i2c slave device, the above path is
triggered, which breaks the assumption that the i2c device is always
runtime resumed whenever the dw_i2c_plat_suspend() is being called.

More precisely, dw_i2c_plat_suspend() calls clk_core_disable() and
clk_core_unprepare(), for an already disabled/unprepared clock, leading to
a splat in the log about clocks calls being wrongly balanced and breaking
system sleep.

To still allow the direct_complete path in cases when it's possible, but
also to keep the fix simple, let's runtime resume the i2c device in the
->suspend() callback, before continuing to put the device into low power
state.

Note, in cases when the i2c device is attached to the ACPI PM domain, this
problem doesn't occur, because ACPI's ->suspend() callback, assigned to
acpi_subsys_suspend(), already calls pm_runtime_resume() for the device.

It should also be noted that this change does not fix commit 8503ff166504
("i2c: designware: Avoid unnecessary resuming during system suspend").
Because for the non-ACPI case, the system sleep support was already broken
prior that point.

Signed-off-by: Ulf Hansson 
Acked-by: Rafael J. Wysocki 
Tested-by: John Stultz 
Tested-by: Jarkko Nikula 
Acked-by: Jarkko Nikula 
Reviewed-by: Mika Westerberg 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: brcmstb: Fix START and STOP conditions

2017-07-05T12:40:30+00:00

commit 2de3ec4f1d4ba6ee380478055104eb918bd50cce upstream.

The BSC data buffers to send and receive data are each of size 32 bytes
or 8 bytes 'xfersz' depending on SoC. The problem observed for all the
combined message transfer was if length of data transfer was a multiple
of 'xfersz' a repeated START was being transmitted by BSC driver. Fixed
this by appropriately setting START/STOP conditions for such transfers.

Fixes: dd1aa2524bc5 ("i2c: brcmstb: Add Broadcom settop SoC i2c controller driver")
Signed-off-by: Jaedon Shin 
Acked-by: Kamal Dasu 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: piix4: Fix request_region size

2017-06-17T04:41:50+00:00

[ Upstream commit f43128c75202f29ee71aa83e6c320a911137c189 ]

Since '701dc207bf55 ("i2c: piix4: Avoid race conditions with IMC")' we
are using the SMBSLVCNT register at offset 0x8. We need to request it.

Fixes: 701dc207bf55 ("i2c: piix4: Avoid race conditions with IMC")
Signed-off-by: Ricardo Ribalda Delgado 
Signed-off-by: Jean Delvare 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: piix4: Request the SMBUS semaphore inside the mutex

2017-06-17T04:41:50+00:00

[ Upstream commit bbb27fc33d44e7b8d96369810654df4ee1837566 ]

SMBSLVCNT must be protected with the piix4_mutex_sb800 in order to avoid
multiple buses accessing to the semaphore at the same time.

Fixes: 701dc207bf55 ("i2c: piix4: Avoid race conditions with IMC")
Reported-by: Jean Delvare 
Signed-off-by: Ricardo Ribalda Delgado 
Signed-off-by: Jean Delvare 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

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

2017-06-07T10:07:46+00:00

commit 5165da5923d6c7df6f2927b0113b2e4d9288661e upstream.

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 ]---

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

i2c: bcm2835: Fix hang for writing messages larger than 16 bytes

2017-04-18T05:11:47+00:00

commit e2474541032db65d02bf88b6a8c2f954654b443f upstream.

Writing messages larger than the FIFO size results in a hang, rendering
the machine unusable. This is because the RXD status flag is set on the
first interrupt which results in bcm2835_drain_rxfifo() stealing bytes
from the buffer. The controller continues to trigger interrupts waiting
for the missing bytes, but bcm2835_fill_txfifo() has none to give.
In this situation wait_for_completion_timeout() apparently is unable to
stop the madness.

The BCM2835 ARM Peripherals datasheet has this to say about the flags:
  TXD: is set when the FIFO has space for at least one byte of data.
  RXD: is set when the FIFO contains at least one byte of data.
  TXW: is set during a write transfer and the FIFO is less than full.
  RXR: is set during a read transfer and the FIFO is or more full.

Implementing the logic from the downstream i2c-bcm2708 driver solved
the hang problem.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Eric Anholt 
Reviewed-by: Martin Sperl 
Signed-off-by: Wolfram Sang 
Signed-off-by: Amit Pundir 
Signed-off-by: Greg Kroah-Hartman

i2c: add missing of_node_put in i2c_mux_del_adapters

2017-03-18T11:14:30+00:00

commit 2e1e4949f9dfb053122785cd73540bb1e61f768b upstream.

Refcount of of_node is increased with of_node_get() in i2c_mux_add_adapter().
It must be decreased with of_node_put() in i2c_mux_del_adapters().

Signed-off-by: Qi Hou 
Reviewed-by: Zhang Xiao 
Signed-off-by: Peter Rosin 
Signed-off-by: Greg Kroah-Hartman

Revert "i2c: designware: detect when dynamic tar update is possible"

2017-02-23T16:44:36+00:00

commit 12688dc21f71f4dcc9e2b8b5556b0c6cc8df1491 upstream.

This reverts commit 63d0f0a6952a1a02bc4f116b7da7c7887e46efa3.

It caused a regression on platforms where I2C controller is synthesized
with dynamic TAR update disabled. Detection code is testing is bit
DW_IC_CON_10BITADDR_MASTER in register DW_IC_CON read-only but fails to
restore original value in case bit is read-write.

Instead of fixing this we revert the commit since it was preparation for
the commit 0317e6c0f1dc ("i2c: designware: do not disable adapter after
transfer") which was also reverted.

Reported-by: Shah Nehal-Bakulchandra 
Reported-by: Suravee Suthikulpanit 
Acked-By: Lucas De Marchi 
Fixes: 63d0f0a6952a ("i2c: designware: detect when dynamic tar update is possible")
Signed-off-by: Jarkko Nikula 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman