kernel/linux.git/drivers/i2c, branch v5.15.7

i2c: cbus-gpio: set atomic transfer callback

2021-12-08T08:04:46+00:00

commit b12764695c3fcade145890b67f82f8b139174cc7 upstream. CBUS transfers have always been atomic, but after commit 63b96983a5dd ("i2c: core: introduce callbacks for atomic transfers") we started to see warnings during e.g. poweroff as the atomic callback is not explicitly set. Fix that. Fixes the following WARNING seen during Nokia N810 power down: [ 786.570617] reboot: Power down [ 786.573913] ------------[ cut here ]------------ [ 786.578826] WARNING: CPU: 0 PID: 672 at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x100/0x110 [ 786.587799] No atomic I2C transfer handler for 'i2c-2' Fixes: 63b96983a5dd ("i2c: core: introduce callbacks for atomic transfers") Signed-off-by: Aaro Koskinen Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: stm32f7: stop dma transfer in case of NACK

2021-12-08T08:04:46+00:00

commit 31b90a95ccbbb4b628578ac17e3b3cc8eeacfe31 upstream. In case of receiving a NACK, the dma transfer should be stopped to avoid feeding data into the FIFO. Also ensure to properly return the proper error code and avoid waiting for the end of the dma completion in case of error happening during the transmission. Fixes: 7ecc8cfde553 ("i2c: i2c-stm32f7: Add DMA support") Signed-off-by: Alain Volmat Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: stm32f7: recover the bus on access timeout

2021-12-08T08:04:46+00:00

commit b933d1faf8fa30d16171bcff404e39c41b2a7c84 upstream. When getting an access timeout, ensure that the bus is in a proper state prior to returning the error. Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver") Signed-off-by: Alain Volmat Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: stm32f7: flush TX FIFO upon transfer errors

2021-12-08T08:04:46+00:00

commit 0c21d02ca469574d2082379db52d1a27b99eed0c upstream. While handling an error during transfer (ex: NACK), it could happen that the driver has already written data into TXDR before the transfer get stopped. This commit add TXDR Flush after end of transfer in case of error to avoid sending a wrong data on any other slave upon next transfer. Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver") Signed-off-by: Alain Volmat Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

i2c: virtio: disable timeout handling

2021-12-01T08:04:50+00:00

[ Upstream commit 84e1d0bf1d7121759622dabf8fbef4c99ad597c5 ] If a timeout is hit, it can result is incorrect data on the I2C bus and/or memory corruptions in the guest since the device can still be operating on the buffers it was given while the guest has freed them. Here is, for example, the start of a slub_debug splat which was triggered on the next transfer after one transfer was forced to timeout by setting a breakpoint in the backend (rust-vmm/vhost-device): BUG kmalloc-1k (Not tainted): Poison overwritten First byte 0x1 instead of 0x6b Allocated in virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29 __kmalloc+0xc2/0x1c9 virtio_i2c_xfer+0x65/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Freed in virtio_i2c_xfer+0x32e/0x35c age=244 cpu=0 pid=29 kfree+0x1bd/0x1cc virtio_i2c_xfer+0x32e/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 There is no simple fix for this (the driver would have to always create bounce buffers and hold on to them until the device eventually returns the buffers), so just disable the timeout support for now. Fixes: 3cfc88380413d20f ("i2c: virtio: add a virtio i2c frontend driver") Acked-by: Jie Deng Signed-off-by: Vincent Whitchurch Acked-by: Michael S. Tsirkin Reviewed-by: Viresh Kumar Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: xlr: Fix a resource leak in the error handling path of 'xlr_i2c_probe()'

2021-11-18T18:17:04+00:00

[ Upstream commit 7f98960c046ee1136e7096aee168eda03aef8a5d ] A successful 'clk_prepare()' call should be balanced by a corresponding 'clk_unprepare()' call in the error handling path of the probe, as already done in the remove function. More specifically, 'clk_prepare_enable()' is used, but 'clk_disable()' is also already called. So just the unprepare step has still to be done. Update the error handling path accordingly. Fixes: 75d31c2372e4 ("i2c: xlr: add support for Sigma Designs controller variant") Signed-off-by: Christophe JAILLET Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: mediatek: fixing the incorrect register offset

2021-11-18T18:16:59+00:00

[ Upstream commit b8228aea5a19d5111a7bf44f7de6749d1f5d487a ] The reason for the modification here is that the previous offset information is incorrect, OFFSET_DEBUGSTAT = 0xE4 is the correct value. Fixes: 25708278f810 ("i2c: mediatek: Add i2c support for MediaTek MT8183") Signed-off-by: Kewei Xu Reviewed-by: Chen-Yu Tsai Reviewed-by: Qii Wang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: i801: Use PCI bus rescan mutex to protect P2SB access

2021-11-18T18:16:59+00:00

[ Upstream commit 7d6b61c394a42b8385858bb9e306d48a0112823c ] As pointed out by Andy in [0] using a local mutex here isn't strictly wrong but not sufficient. We should hold the PCI rescan lock for P2SB operations. [0] https://www.spinics.net/lists/linux-i2c/msg52717.html Fixes: 1a987c69ce2c ("i2c: i801: make p2sb_spinlock a mutex") Reported-by: Andy Shevchenko Signed-off-by: Heiner Kallweit Reviewed-by: Andy Shevchenko Reviewed-by: Jean Delvare Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: mlxcpld: Modify register setting for 400KHz frequency

2021-10-04T19:56:20+00:00

Change setting for 400KHz frequency support by more accurate value. Fixes: 66b0c2846ba8 ("i2c: mlxcpld: Add support for I2C bus frequency setting") Signed-off-by: Vadim Pasternak Signed-off-by: Wolfram Sang

i2c: mlxcpld: Fix criteria for frequency setting

2021-10-04T19:56:13+00:00

Value for getting frequency capability wrongly has been taken from register offset instead of register value. Fixes: 66b0c2846ba8 ("i2c: mlxcpld: Add support for I2C bus frequency setting") Signed-off-by: Vadim Pasternak Signed-off-by: Wolfram Sang