Wind River Support Network

Description

The customer is using xilinx-zinq BSP.
He has upgraded the WR build system from LTS18 v10.18.44.10 to v10.18.44.17. To validate the migration he used some proprietary tests which on RCPL10 were successful but on RCPL17 they led to the following problem.

The i2c goes in timeout running into one of the following scenarios:

i. “Kernel stack is corrupted in: i2c_smbus_xfer+0x460/0x990”
ii. Kernel Ops which tries to access an invalid virtual address ffffffff

In RCPL10 the problem was not present. Adding the following patch in RCPL17 led to regression. 

a49f32b3cb4c1dc38846eb10ecef205e390625fa
Author: Quanyang Wang <quanyang.wang@windriver.com>
Date: Thu Oct 24 18:25:58 2019 +0800

i2c: cadence: keep bus_hold_flag unless I2C_M_NOSTART is set
 
 When using i2c_smbus_read_byte_data to read one byte from a
 slave device, because of the commit d358def70688
 ("i2c: cadence: Fix the hold bit setting"), the transaction becomes:
 
 S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P
 ^
 CR_HOLD bit as 0
 
 This will result that the read operation fails and will read "0xff" from
 the slave device. In the SMBus protocol, it stipulates that it must follow
 that command with a repeated START condition as below:
 
 S Addr Wr [A] Comm [A] Sr Addr Rd [A] [Data] NA P
 
 So add a check if I2C_M_NOSTART is set in flags. If set, clear the
 CR_HOLD bit, or else keep CR_HOLD bit to be 1 to make sure that
 the read operation begins with a repeated START.
 
 Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
 Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>\

The customer has reverted this patch and the problem has disappeared.