linux/drivers/i2c, branch v6.4

i2c: imx-lpi2c: fix type char overflow issue when calculating the clock cycle

2023-06-23T10:58:24Z

Claim clkhi and clklo as integer type to avoid possible calculation errors caused by data overflow. Fixes: a55fa9d0e42e ("i2c: imx-lpi2c: add low power i2c bus driver") Signed-off-by: Clark Wang Signed-off-by: Carlos Song Reviewed-by: Andi Shyti Signed-off-by: Wolfram Sang

i2c: qup: Add missing unwind goto in qup_i2c_probe()

2023-06-23T10:58:24Z

Smatch Warns: drivers/i2c/busses/i2c-qup.c:1784 qup_i2c_probe() warn: missing unwind goto? The goto label "fail_runtime" and "fail" will disable qup->pclk, but here qup->pclk failed to obtain, in order to be consistent, change the direct return to goto label "fail_dma". Fixes: 9cedf3b2f099 ("i2c: qup: Add bam dma capabilities") Signed-off-by: Shuai Jiang Reviewed-by: Dongliang Mu Reviewed-by: Andi Shyti Signed-off-by: Wolfram Sang Cc: # v4.6+

i2c: sprd: Delete i2c adapter in .remove's error path

2023-06-07T10:29:58Z

If pm runtime resume fails the .remove callback used to exit early. This resulted in an error message by the driver core but the device gets removed anyhow. This lets the registered i2c adapter stay around with an unbound parent device. So only skip clk disabling if resume failed, but do delete the adapter. Fixes: 8b9ec0719834 ("i2c: Add Spreadtrum I2C controller driver") Signed-off-by: Uwe Kleine-König Reviewed-by: Andi Shyti Signed-off-by: Wolfram Sang

i2c: mv64xxx: Fix reading invalid status value in atomic mode

2023-06-05T10:22:30Z

There seems to be a bug within the mv64xxx I2C controller, wherein the status register may not necessarily contain valid value immediately after the IFLG flag is set in the control register. My theory is that the controller: - first sets the IFLG in control register - then updates the status register - then raises an interrupt This may sometime cause weird bugs when in atomic mode, since in this mode we do not wait for an interrupt, but instead we poll the control register for IFLG and read status register immediately after. I encountered -ENXIO from mv64xxx_i2c_fsm() due to this issue when using this driver in atomic mode. Note that I've only seen this issue on Armada 385, I don't know whether other SOCs with this controller are also affected. Also note that this fix has been in U-Boot for over 4 years [1] without anybody complaining, so it should not cause regressions. [1] https://source.denx.de/u-boot/u-boot/-/commit/d50e29662f78 Fixes: 544a8d75f3d6 ("i2c: mv64xxx: Add atomic_xfer method to driver") Signed-off-by: Marek Behún Signed-off-by: Wolfram Sang

i2c: designware: fix idx_write_cnt in read loop

2023-06-05T09:58:20Z

With IC_INTR_RX_FULL slave interrupt handler reads data in a loop until RX FIFO is empty. When testing with the slave-eeprom, each transaction has 2 bytes for address/index and 1 byte for value, the address byte can be written as data byte due to dropping STOP condition. In the test below, the master continuously writes to the slave, first 2 bytes are index, 3rd byte is value and follow by a STOP condition. i2c_write: i2c-3 #0 a=04b f=0000 l=3 [00-D1-D1] i2c_write: i2c-3 #0 a=04b f=0000 l=3 [00-D2-D2] i2c_write: i2c-3 #0 a=04b f=0000 l=3 [00-D3-D3] Upon receiving STOP condition slave eeprom would reset `idx_write_cnt` so next 2 bytes can be treated as buffer index for upcoming transaction. Supposedly the slave eeprom buffer would be written as EEPROM[0x00D1] = 0xD1 EEPROM[0x00D2] = 0xD2 EEPROM[0x00D3] = 0xD3 When CPU load is high the slave irq handler may not read fast enough, the interrupt status can be seen as 0x204 with both DW_IC_INTR_STOP_DET (0x200) and DW_IC_INTR_RX_FULL (0x4) bits. The slave device may see the transactions below. 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1794 : INTR_STAT=0x204 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x1790 : INTR_STAT=0x200 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4 After `D1` is received, read loop continues to read `00` which is the first bype of next index. Since STOP condition is ignored by the loop, eeprom buffer index increased to `D2` and `00` is written as value. So the slave eeprom buffer becomes EEPROM[0x00D1] = 0xD1 EEPROM[0x00D2] = 0x00 EEPROM[0x00D3] = 0xD3 The fix is to use `FIRST_DATA_BYTE` (bit 11) in `IC_DATA_CMD` to split the transactions. The first index byte in this case would have bit 11 set. Check this indication to inject I2C_SLAVE_WRITE_REQUESTED event which will reset `idx_write_cnt` in slave eeprom. Signed-off-by: David Zheng Acked-by: Jarkko Nikula Signed-off-by: Wolfram Sang

i2c: mchp-pci1xxxx: Avoid cast to incompatible function type

2023-06-05T08:43:45Z

Rather than casting pci1xxxx_i2c_shutdown to an incompatible function type, update the type to match that expected by __devm_add_action. Reported by clang-16 with W-1: .../i2c-mchp-pci1xxxx.c:1159:29: error: cast from 'void (*)(struct pci1xxxx_i2c *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] ret = devm_add_action(dev, (void (*)(void *))pci1xxxx_i2c_shutdown, i2c); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/device.h:251:29: note: expanded from macro 'devm_add_action' __devm_add_action(release, action, data, #action) ^~~~~~ No functional change intended. Compile tested only. Signed-off-by: Simon Horman Reviewed-by: Horatiu Vultur Reviewed-by: Andi Shyti Reviewed-by: Tharun Kumar P Signed-off-by: Wolfram Sang

i2c: img-scb: Fix spelling mistake "innacurate" -> "inaccurate"

2023-06-05T08:39:11Z

There is a spelling mistake in a comment. Fix it. Signed-off-by: Christian Heusel Signed-off-by: Wolfram Sang

i2c: gxp: fix build failure without CONFIG_I2C_SLAVE

2023-05-03T15:27:29Z

The gxp_i2c_slave_irq_handler() is hidden in an #ifdef, but the caller uses an IS_ENABLED() check: drivers/i2c/busses/i2c-gxp.c: In function 'gxp_i2c_irq_handler': drivers/i2c/busses/i2c-gxp.c:467:29: error: implicit declaration of function 'gxp_i2c_slave_irq_handler'; did you mean 'gxp_i2c_irq_handler'? [-Werror=implicit-function-declaration] It has to consistently use one method or the other to avoid warnings, so move to IS_ENABLED() here for readability and build coverage, and move the #ifdef in linux/i2c.h to allow building it as dead code. Fixes: 4a55ed6f89f5 ("i2c: Add GXP SoC I2C Controller") Signed-off-by: Arnd Bergmann Reviewed-by: Nick Hawkins Signed-off-by: Wolfram Sang

i2c: imx-lpi2c: avoid taking clk_prepare mutex in PM callbacks

2023-05-03T15:27:29Z

This is unsafe, as the runtime PM callbacks are called from the PM workqueue, so this may deadlock when handling an i2c attached clock, which may already hold the clk_prepare mutex from another context. Signed-off-by: Alexander Stein Signed-off-by: Wolfram Sang

i2c: omap: Fix standard mode false ACK readings

2023-05-03T15:27:21Z

Using standard mode, rare false ACK responses were appearing with i2cdetect tool. This was happening due to NACK interrupt triggering ISR thread before register access interrupt was ready. Removing the NACK interrupt's ability to trigger ISR thread lets register access ready interrupt do this instead. Cc: # v3.7+ Fixes: 3b2f8f82dad7 ("i2c: omap: switch to threaded IRQ support") Signed-off-by: Reid Tonking Acked-by: Vignesh Raghavendra Reviewed-by: Tony Lindgren Signed-off-by: Wolfram Sang