linux/drivers/i2c, branch v6.13

i2c: testunit: on errors, repeat NACK until STOP

2025-01-15T18:44:21Z

This backend requests a NACK from the controller driver when it detects an error. If that request gets ignored from some reason, subsequent accesses will wrongly be handled OK. To fix this, an error now changes the state machine, so the backend will report NACK until a STOP condition has been detected. This make the driver more robust against controllers which will sadly apply the NACK not to the current byte but the next one. Fixes: a8335c64c5f0 ("i2c: add slave testunit driver") Signed-off-by: Wolfram Sang

i2c: rcar: fix NACK handling when being a target

2025-01-15T18:37:33Z

When this controller is a target, the NACK handling had two issues. First, the return value from the backend was not checked on the initial WRITE_REQUESTED. So, the driver missed to send a NACK in this case. Also, the NACK always arrives one byte late on the bus, even in the WRITE_RECEIVED case. This seems to be a HW issue. We should then not rely on the backend to correctly NACK the superfluous byte as well. Fix both issues by introducing a flag which gets set whenever the backend requests a NACK and keep sending it until we get a STOP condition. Fixes: de20d1857dd6 ("i2c: rcar: add slave support") Signed-off-by: Wolfram Sang

i2c: mux: demux-pinctrl: correct comment

2025-01-15T18:37:16Z

Two characters flipped, fix them. Signed-off-by: Wolfram Sang

i2c: mux: demux-pinctrl: check initial mux selection, too

2025-01-15T18:37:07Z

When misconfigured, the initial setup of the current mux channel can fail, too. It must be checked as well. Fixes: 50a5ba876908 ("i2c: mux: demux-pinctrl: add driver") Signed-off-by: Wolfram Sang

i2c: atr: Fix client detach

2025-01-09T10:08:01Z

i2c-atr catches the BUS_NOTIFY_DEL_DEVICE event on the bus and removes the translation by calling i2c_atr_detach_client(). However, BUS_NOTIFY_DEL_DEVICE happens when the device is about to be removed from this bus, i.e. before removal, and thus before calling .remove() on the driver. If the driver happens to do any i2c transactions in its remove(), they will fail. Fix this by catching BUS_NOTIFY_REMOVED_DEVICE instead, thus removing the translation only after the device is actually removed. Fixes: a076a860acae ("media: i2c: add I2C Address Translator (ATR) support") Cc: stable@vger.kernel.org Signed-off-by: Tomi Valkeinen Reviewed-by: Luca Ceresoli Reviewed-by: Romain Gantois Tested-by: Romain Gantois Signed-off-by: Wolfram Sang

i2c: core: fix reference leak in i2c_register_adapter()

2025-01-09T10:02:31Z

The reference count of the device incremented in device_initialize() is not decremented when device_add() fails. Add a put_device() call before returning from the function. This bug was found by an experimental static analysis tool that I am developing. Fixes: 60f68597024d ("i2c: core: Setup i2c_adapter runtime-pm before calling device_add()") Signed-off-by: Joe Hattori Signed-off-by: Wolfram Sang

i2c: microchip-core: fix "ghost" detections

2024-12-26T00:54:47Z

Running i2c-detect currently produces an output akin to: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 08 -- 0a -- 0c -- 0e -- 10: 10 -- 12 -- 14 -- 16 -- UU 19 -- 1b -- 1d -- 1f 20: -- 21 -- 23 -- 25 -- 27 -- 29 -- 2b -- 2d -- 2f 30: -- -- -- -- -- -- -- -- 38 -- 3a -- 3c -- 3e -- 40: 40 -- 42 -- 44 -- 46 -- 48 -- 4a -- 4c -- 4e -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: 60 -- 62 -- 64 -- 66 -- 68 -- 6a -- 6c -- 6e -- 70: 70 -- 72 -- 74 -- 76 -- This happens because for an i2c_msg with a len of 0 the driver will mark the transmission of the message as a success once the START has been sent, without waiting for the devices on the bus to respond with an ACK/NAK. Since i2cdetect seems to run in a tight loop over all addresses the NAK is treated as part of the next test for the next address. Delete the fast path that marks a message as complete when idev->msg_len is zero after sending a START/RESTART since this isn't a valid scenario. CC: stable@vger.kernel.org Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers") Signed-off-by: Conor Dooley Reviewed-by: Andi Shyti Link: https://lore.kernel.org/r/20241218-outbid-encounter-b2e78b1cc707@spud Signed-off-by: Andi Shyti

i2c: microchip-core: actually use repeated sends

2024-12-26T00:54:47Z

At present, where repeated sends are intended to be used, the i2c-microchip-core driver sends a stop followed by a start. Lots of i2c devices must not malfunction in the face of this behaviour, because the driver has operated like this for years! Try to keep track of whether or not a repeated send is required, and suppress sending a stop in these cases. CC: stable@vger.kernel.org Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers") Signed-off-by: Conor Dooley Reviewed-by: Andi Shyti Link: https://lore.kernel.org/r/20241218-football-composure-e56df2461461@spud Signed-off-by: Andi Shyti

i2c: imx: add imx7d compatible string for applying erratum ERR007805

2024-12-25T22:45:05Z

Compatible string "fsl,imx7d-i2c" is not exited at i2c-imx driver compatible string table, at the result, "fsl,imx21-i2c" will be matched, but it will cause erratum ERR007805 not be applied in fact. So Add "fsl,imx7d-i2c" compatible string in i2c-imx driver to apply the erratum ERR007805(https://www.nxp.com/docs/en/errata/IMX7DS_3N09P.pdf). " ERR007805 I2C: When the I2C clock speed is configured for 400 kHz, the SCL low period violates the I2C spec of 1.3 uS min Description: When the I2C module is programmed to operate at the maximum clock speed of 400 kHz (as defined by the I2C spec), the SCL clock low period violates the I2C spec of 1.3 uS min. The user must reduce the clock speed to obtain the SCL low time to meet the 1.3us I2C minimum required. This behavior means the SoC is not compliant to the I2C spec at 400kHz. Workaround: To meet the clock low period requirement in fast speed mode, SCL must be configured to 384KHz or less. " "fsl,imx7d-i2c" already is documented in binding doc. This erratum fix has been included in imx6_i2c_hwdata and it is the same in all I.MX6/7/8, so just reuse it. Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit") Cc: stable@vger.kernel.org # v5.18+ Signed-off-by: Carlos Song Signed-off-by: Haibo Chen Reviewed-by: Frank Li Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit") Acked-by: Oleksij Rempel Link: https://lore.kernel.org/r/20241218044238.143414-1-carlos.song@nxp.com Signed-off-by: Andi Shyti

i2c: imx: fix missing stop condition in single-master mode

2024-12-25T22:45:04Z

A regression was introduced with the implementation of single-master mode, preventing proper stop conditions from being generated. Devices that require a valid stop condition, such as EEPROMs, fail to function correctly as a result. The issue only affects devices with the single-master property enabled. This commit resolves the issue by re-enabling I2C bus busy bit (IBB) polling for single-master mode when generating a stop condition. The fix further ensures that the i2c_imx->stopped flag is cleared at the start of each transfer, allowing the stop condition to be correctly generated in i2c_imx_stop(). According to the reference manual (IMX8MMRM, Rev. 2, 09/2019, page 5270), polling the IBB bit to determine if the bus is free is only necessary in multi-master mode. Consequently, the IBB bit is not polled for the start condition in single-master mode. Fixes: 6692694aca86 ("i2c: imx: do not poll for bus busy in single master mode") Signed-off-by: Stefan Eichenberger Reviewed-by: Frank Li Reviewed-by: Francesco Dolcini Link: https://lore.kernel.org/r/20241216151829.74056-1-eichest@gmail.com Signed-off-by: Andi Shyti