linux-toradex.git/drivers/i2c, branch v3.14.20

i2c: ismt: use correct length when copy buffer

2014-10-05T21:52:11+00:00

commit 979bbf7b7ae75cfc06e09d09eda38009a3bdc4a4 upstream.

In block write mode, when encapsulating dma_buffer, first element is
'command', the rest is data buffer, so only copy actual data buffer
starting from block[1] with the size indicating by block[0].

Signed-off-by: Fan Du 
Acked-by: Neil Horman 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: at91: Fix a race condition during signal handling in at91_do_twi_xfer.

2014-10-05T21:52:11+00:00

commit 6721f28a26efd6368497abbdef5dcfc59608d899 upstream.

There is a race condition in at91_do_twi_xfer when signals arrive.
If a signal is recieved while waiting for a transfer to complete
wait_for_completion_interruptible_timeout() will return -ERESTARTSYS.
This is not handled correctly resulting in interrupts still being
enabled and a transfer being in flight when we return.

Symptoms include a range of oopses and bus lockups. Oopses can happen
when the transfer completes because the interrupt handler will corrupt
the stack. If a new transfer is started before the interrupt fires
the controller will start a new transfer in the middle of the old one,
resulting in confused slaves and a locked bus.

To avoid this, use wait_for_completion_io_timeout instead so that we
don't have to deal with gracefully shutting down the transfer and
disabling the interrupts.

Signed-off-by: Simon Lindgren 
Acked-by: Ludovic Desroches 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: at91: add bound checking on SMBus block length bytes

2014-10-05T21:52:11+00:00

commit 75b81f339c6af43f6f4a1b3eabe0603321dade65 upstream.

The driver was not bound checking the received length byte to ensure it was within the
the buffer size that is allocated for SMBus blocks. This resulted in buffer overflows
whenever an invalid length byte was received.
It also failed to ensure the length byte was not zero. If it received zero, it would end up
in an infinite loop as the at91_twi_read_next_byte function returned immediately without
allowing RHR to be read to clear the RXRDY interrupt.

Tested agaisnt a SMBus compliant battery.

Signed-off-by: Marek Roszko 
Acked-by: Ludovic Desroches 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: mv64xxx: continue probe when clock-frequency is missing

2014-10-05T21:52:11+00:00

commit 0ce4bc1dbdd911ae1763e2d4ff36bd1b214a59f7 upstream.

The "clock-frequency" DT property is listed as optional, However,
the current code stores the return value of of_property_read_u32 in
the return code of mv64xxx_of_config, but then forgets to clear it
after setting the default value of "clock-frequency". It is then
passed out to the main probe function, resulting in a probe failure
when "clock-frequency" is missing.

This patch checks and then throws away the return value of
of_property_read_u32, instead of storing it and having to clear it
afterwards.

This issue was discovered after the property was removed from all
sunxi DTs.

Fixes: 4c730a06c19bb ("i2c: mv64xxx: Set bus frequency to 100kHz if clock-frequency is not provided")
Signed-off-by: Chen-Yu Tsai 
Acked-by: Andrew Lunn 
Acked-by: Maxime Ripard 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

drivers/i2c/busses: use correct type for dma_map/unmap

2014-09-05T23:34:14+00:00

commit 28772ac8711e4d7268c06e765887dd8cb6924f98 upstream.

dma_{un}map_* uses 'enum dma_data_direction' not 'enum dma_transfer_direction'.

Signed-off-by: Wolfram Sang 
Acked-by: Ludovic Desroches 
Signed-off-by: Greg Kroah-Hartman

i2c: s3c2410: resume race fix

2014-06-07T17:28:27+00:00

commit ce78cc071f5f541480e381cc0241d37590041a9d upstream.

Don't unmark the device as suspended until after it's been re-setup.

The main race would be w.r.t. an i2c driver that gets resumed at the same
time (asyncronously), that is allowed to do a transfer since suspended
is set to 0 before reinit, but really should have seen the -EIO return
instead.

Signed-off-by: Olof Johansson 
Signed-off-by: Doug Anderson 
Acked-by: Kukjin Kim 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: designware: Mask all interrupts during i2c controller enable

2014-06-07T17:28:27+00:00

commit 47bb27e78867997040a228328f2a631c3c7f2c82 upstream.

There have been "i2c_designware 80860F41:00: controller timed out" errors
on a number of Baytrail platforms. The issue is caused by incorrect value in
Interrupt Mask Register (DW_IC_INTR_MASK)  when i2c core is being enabled.
This causes call to __i2c_dw_enable() to immediately start the transfer which
leads to timeout. There are 3 failure modes observed:

1. Failure in S0 to S3 resume path

The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start
the first transaction after resuming from system sleep, TX_EMPTY interrupt
is already unmasked because of the hardware default.

2. Failure in normal operational path

This failure happens rarely and is hard to reproduce. Debug trace showed that
DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant
TX_EMPTY was unmasked.

3. Failure in S3 to S0 suspend path

This failure also happens rarely and is hard to reproduce. Adding debug trace
that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR
call trace we could conclude TX_EMPTY was unmasked when problem occurred.

The patch masks all interrupts before the controller is enabled to resolve the
faulty DW_IC_INTR_MASK conditions.

Signed-off-by: Wenkai Du 
Acked-by: Mika Westerberg 
[wsa: improved the comment and removed typo in commit msg]
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: rcar: bail out on zero length transfers

2014-06-07T17:28:27+00:00

commit d7653964c590ba846aa11a8f6edf409773cbc492 upstream.

This hardware does not support zero length transfers. Instead, the
driver does one (random) byte transfers currently with undefined results
for the slaves. We now bail out.

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

i2c: i801: enable Intel BayTrail SMBUS

2014-06-07T17:28:19+00:00

commit 1b31e9b76ef8c62291e698dfdb973499986a7f68 upstream.

Add Device ID of Intel BayTrail SMBus Controller.

Signed-off-by: Chew, Kean ho 
Signed-off-by: Chew, Chiau Ee 
Reviewed-by: Jean Delvare 
Signed-off-by: Wolfram Sang 
Cc: "Chang, Rebecca Swee Fun" 
Signed-off-by: Greg Kroah-Hartman

i2c: cpm: Fix build by adding of_address.h and of_irq.h

2014-03-24T13:54:21+00:00

Fixes a build break due to the undeclared use of irq_of_parse_and_map()
and of_iomap().  This build break was apparently introduced while the
driver was unbuildable due to the bug fixed by
62c19c9d29e65086e5ae76df371ed2e6b23f00cd ("i2c: Remove usage of
orphaned symbol OF_I2C").  When 62c19c was added in v3.14-rc7,
the driver was enabled again, breaking the powerpc mpc85xx_defconfig
and mpc85xx_smp_defconfig.

62c19c is marked for stable, so this should go there as well.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Scott Wood 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org