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

i2c: riic: fix restart condition

2017-12-14T08:28:21+00:00

[ Upstream commit 2501c1bb054290679baad0ff7f4f07c714251f4c ]

While modifying the driver to use the STOP interrupt, the completion of the
intermediate transfers need to wake the driver back up in order to initiate
the next transfer (restart condition). Otherwise you get never ending
interrupts and only the first transfer sent.

Fixes: 71ccea095ea1 ("i2c: riic: correctly finish transfers")
Reported-by: Simon Horman 
Signed-off-by: Chris Brandt 
Tested-by: Simon Horman 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: i2c-cadence: Initialize configuration before probing devices

2017-12-09T21:01:53+00:00

[ Upstream commit 0e1929dedea36781e25902118c93edd8d8f09af1 ]

The cadence I2C driver calls cdns_i2c_writereg(..) to setup a workaround
in the controller, but did so after calling i2c_add_adapter() which starts
probing devices on the bus. Change the order so that the configuration is
completely finished before using the adapter.

Signed-off-by: Mike Looijmans 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: i801: Fix Failed to allocate irq -2147483648 error

2017-12-05T10:24:34+00:00

commit 6e0c9507bf51e1517a80ad0ac171e5402528fcef upstream.

On Apollo Lake devices the BIOS does not set up IRQ routing for the i801
SMBUS controller IRQ, so we end up with dev->irq set to IRQ_NOTCONNECTED.

Detect this and do not try to use the irq in this case silencing:
i801_smbus 0000:00:1f.1: Failed to allocate irq -2147483648: -107

BugLink: https://communities.intel.com/thread/114759
Signed-off-by: Hans de Goede 
Reviewed-by: Jean Delvare 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: riic: correctly finish transfers

2017-11-08T09:08:34+00:00

[ Upstream commit 71ccea095ea1d4efd004dab971be6d599e06fc3f ]

This fixes the condition where the controller has not fully completed its
final transfer and leaves the bus and controller in a undesirable state.

At the end of the last transmitted byte, the existing driver would just
signal for a STOP condition to be transmitted then immediately signal
completion. However, the full STOP procedure might not have fully taken
place by the time the runtime PM shuts off the peripheral clock, leaving
the bus in a suspended state.

Alternatively, the STOP condition on the bus may have completed, but when
the next transaction is requested by the upper layer, not all the
necessary register cleanup was finished from the last transfer which made
the driver return BUS BUSY when it really wasn't.

This patch now makes all transmit and receive transactions wait for the
STOP condition to fully complete before signaling a completed transaction.
With this new method, runtime PM no longer seems to be an issue.

Fixes: 310c18a41450 ("i2c: riic: add driver")
Signed-off-by: Chris Brandt 
Reviewed-by: Wolfram Sang 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: piix4: Fix SMBus port selection for AMD Family 17h chips

2017-10-27T08:38:07+00:00

commit 0fe16195f89173652cf111d7b384941b00c5aabd upstream.

AMD Family 17h uses the KERNCZ SMBus controller. While its documentation
is not publicly available, it is documented in the BIOS and Kernel
Developer’s Guide for AMD Family 15h Models 60h-6Fh Processors.

On this SMBus controller, the port select register is at PMx register
0x02, bit 4:3 (PMx00 register bit 20:19).

Without this patch, the 4 SMBus channels on AMD Family 17h chips are
mirrored and report the same chips on all channels.

Signed-off-by: Guenter Roeck 
Reviewed-by: Jean Delvare 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: ismt: Separate I2C block read from SMBus block read

2017-10-27T08:38:07+00:00

commit c6ebcedbab7ca78984959386012a17b21183e1a3 upstream.

Commit b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for
block reads") broke I2C block reads. It aimed to fix normal SMBus block
read, but changed the correct behavior of I2C block read in the process.

According to Documentation/i2c/smbus-protocol, one vital difference
between normal SMBus block read and I2C block read is that there is no
byte count prefixed in the data sent on the wire:

 SMBus Block Read:  i2c_smbus_read_block_data()
 S Addr Wr [A] Comm [A]
            S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P

 I2C Block Read:  i2c_smbus_read_i2c_block_data()
 S Addr Wr [A] Comm [A]
            S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P

Therefore the two transaction types need to be processed differently in
the driver by copying of the dma_buffer as done previously for the
I2C_SMBUS_I2C_BLOCK_DATA case.

Fixes: b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for block reads")
Signed-off-by: Pontus Andersson 
Tested-by: Stephen Douthit 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: at91: ensure state is restored after suspending

2017-10-21T15:21:37+00:00

[ Upstream commit e3ccc921b7d8fd1fcd10a00720e09823d8078666 ]

When going to suspend, the I2C registers may be lost because the power to
VDDcore is cut. Restore them when resuming.

Signed-off-by: Alexandre Belloni 
Acked-by: Ludovic Desroches 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: meson: fix wrong variable usage in meson_i2c_put_data

2017-10-08T08:26:11+00:00

[ Upstream commit 3b0277f198ac928f323c42e180680d2f79aa980d ]

Most likely a copy & paste error.

Signed-off-by: Heiner Kallweit 
Acked-by: Jerome Brunet 
Signed-off-by: Wolfram Sang 
Fixes: 30021e3707a7 ("i2c: add support for Amlogic Meson I2C controller")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

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