litmus-rt-ext-res.git/drivers/i2c, branch EXT-RES

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

i2c: mux: pca954x: fix i2c mux selection caching

2017-01-19T19:18:05+00:00

commit 7f638c1cb0a1112dbe0b682a42db30521646686b upstream.

smbus functions return -ve on error, 0 on success.  However,
__i2c_transfer() have a different return signature - -ve on error, or
number of buffers transferred (which may be zero or greater.)

The upshot of this is that the sense of the test is reversed when using
the mux on a bus supporting the master_xfer method: we cache the value
and never retry if we fail to transfer any buffers, but if we succeed,
we clear the cached value.

Fix this by making pca954x_reg_write() return a negative error code for
all failure cases.

Fixes: 463e8f845cbf ("i2c: mux: pca954x: retry updating the mux selection on failure")
Acked-by: Peter Rosin 
Signed-off-by: Russell King 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: piix4: Avoid race conditions with IMC

2017-01-19T19:18:04+00:00

commit 701dc207bf551d9fe6defa36e84a911e880398c3 upstream.

On AMD's SB800 and upwards, the SMBus is shared with the Integrated
Micro Controller (IMC).

The platform provides a hardware semaphore to avoid race conditions
among them. (Check page 288 of the SB800-Series Southbridges Register
Reference Guide http://support.amd.com/TechDocs/45482.pdf)

Without this patch, many access to the SMBus end with an invalid
transaction or even with the bus stalled.

Reported-by: Alexandre Desnoyers 
Signed-off-by: Ricardo Ribalda Delgado 
Reviewed-by: Andy Shevchenko :
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: fix kernel memory disclosure in dev interface

2017-01-19T19:18:02+00:00

commit 30f939feaeee23e21391cfc7b484f012eb189c3c upstream.

i2c_smbus_xfer() does not always fill an entire block, allowing
kernel stack memory disclosure through the temp variable. Clear
it before it's read to.

Signed-off-by: Vlad Tsyrklevich 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: print correct device invalid address

2017-01-19T19:18:02+00:00

commit 6f724fb3039522486fce2e32e4c0fbe238a6ab02 upstream.

In of_i2c_register_device(), when the check for
device address validity fails we print the info.addr,
which has not been assigned properly.

Fix this by printing the actual invalid address.

Signed-off-by: John Garry 
Reviewed-by: Vladimir Zapolskiy 
Signed-off-by: Wolfram Sang 
Fixes: b4e2f6ac1281 ("i2c: apply DT flags when probing")
Signed-off-by: Greg Kroah-Hartman

Revert "i2c: octeon: thunderx: Limit register access retries"

2016-11-29T19:04:21+00:00

This reverts commit 70121f7f3725 ("i2c: octeon: thunderx: Limit register access retries").
Using readq_poll_timeout instead of __raw_readq triggers the following
debug warning:

[   78.871568] ipmi_ssif: Trying hotmod-specified SSIF interface at i2c address 0x12, adapter Cavium ThunderX i2c adapter at 0000:01:09.4, slave address 0x0
[   78.886107] do not call blocking ops when !TASK_RUNNING; state=2 set at [] prepare_to_wait_event+0x58/0x10c
[   78.897436] ------------[ cut here ]------------
[   78.902050] WARNING: CPU: 6 PID: 2235 at kernel/sched/core.c:7718 __might_sleep+0x80/0x88

[...]

[   79.133553] [] __might_sleep+0x80/0x88
[   79.138862] [] octeon_i2c_test_iflg+0x4c/0xbc [i2c_thunderx]
[   79.146077] [] octeon_i2c_test_ready+0x18/0x70 [i2c_thunderx]
[   79.153379] [] octeon_i2c_wait+0x154/0x1a4 [i2c_thunderx]
[   79.160334] [] octeon_i2c_xfer+0xf4/0xf60 [i2c_thunderx]

Signed-off-by: Jan Glauber 
Acked-by: Steven J. Hill 
Signed-off-by: Wolfram Sang

Revert "i2c: designware: do not disable adapter after transfer"

2016-11-25T22:23:25+00:00

This reverts commit 0317e6c0f1dc1ba86b8d9dccc010c5e77b8355fa.

Srinivas reported recently touchscreen and touchpad stopped working in
Haswell based machine in Linux 4.9-rc series with timeout errors from
i2c_designware:

[   16.508013] i2c_designware INT33C3:00: controller timed out
[   16.508302] i2c_hid i2c-MSFT0001:02: failed to change power setting.
[   17.532016] i2c_designware INT33C3:00: controller timed out
[   18.556022] i2c_designware INT33C3:00: controller timed out
[   18.556315] i2c_hid i2c-ATML1000:00: failed to retrieve report from device.

I managed to reproduce similar errors on another Haswell based machine
where touchscreen initialization fails maybe in every 1/5 - 1/2 boots.
Since root cause for these errors is not clear yet and debugging is
ongoing it's better to revert this commit as we are near to release.

Reported-by: Srinivas Pandruvada 
Signed-off-by: Jarkko Nikula 
Signed-off-by: Wolfram Sang

i2c: designware: fix rx fifo depth tracking

2016-11-24T15:18:15+00:00

When loading the TX fifo to receive bytes on the I2C bus, we incorrectly
count the number of bytes:

	rx_limit = dev->rx_fifo_depth - dw_readl(dev, DW_IC_RXFLR);

	while (buf_len > 0 && tx_limit > 0 && rx_limit > 0) {
		if (rx_limit - dev->rx_outstanding <= 0)
			break;
		rx_limit--;
		dev->rx_outstanding++;
	}

DW_IC_RXFLR indicates how many bytes are available to be read in the
FIFO, dev->rx_fifo_depth is the FIFO size, and dev->rx_outstanding is
the number of bytes that we've requested to be read so far, but which
have not been read.

Firstly, increasing dev->rx_outstanding and decreasing rx_limit and then
comparing them results in each byte consuming "two" bytes in this
tracking, so this is obviously wrong.

Secondly, the number of bytes that _could_ be received into the FIFO at
any time is the number of bytes we have so far requested but not yet
read from the FIFO - in other words dev->rx_outstanding.

So, in order to request enough bytes to fill the RX FIFO, we need to
request dev->rx_fifo_depth - dev->rx_outstanding bytes.

Modifying the code thusly results in us reaching the maximum number of
bytes outstanding each time we queue more "receive" operations, provided
the transfer allows that to happen.

Signed-off-by: Russell King 
Reviewed-by: Mika Westerberg 
Acked-by: Jarkko Nikula 
Signed-off-by: Wolfram Sang