kernel/git/stable/linux.git/drivers/i2c, branch linux-4.19.y

i2c: i801: Use a different adapter-name for IDF adapters

2024-11-08T15:19:17+00:00

[ Upstream commit 43457ada98c824f310adb7bd96bd5f2fcd9a3279 ] On chipsets with a second 'Integrated Device Function' SMBus controller use a different adapter-name for the second IDF adapter. This allows platform glue code which is looking for the primary i801 adapter to manually instantiate i2c_clients on to differentiate between the 2. This allows such code to find the primary i801 adapter by name, without needing to duplicate the PCI-ids to feature-flags mapping from i2c-i801.c. Reviewed-by: Pali Rohár Signed-off-by: Hans de Goede Acked-by: Wolfram Sang Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin

i2c: xiic: Wait for TX empty to avoid missed TX NAKs

2024-11-08T15:19:13+00:00

commit 521da1e9225450bd323db5fa5bca942b1dc485b7 upstream. Frequently an I2C write will be followed by a read, such as a register address write followed by a read of the register value. In this driver, when the TX FIFO half empty interrupt was raised and it was determined that there was enough space in the TX FIFO to send the following read command, it would do so without waiting for the TX FIFO to actually empty. Unfortunately it appears that in some cases this can result in a NAK that was raised by the target device on the write, such as due to an unsupported register address, being ignored and the subsequent read being done anyway. This can potentially put the I2C bus into an invalid state and/or result in invalid read data being processed. To avoid this, once a message has been fully written to the TX FIFO, wait for the TX FIFO empty interrupt before moving on to the next message, to ensure NAKs are handled properly. Fixes: e1d5b6598cdc ("i2c: Add support for Xilinx XPS IIC Bus Interface") Signed-off-by: Robert Hancock Cc: # v2.6.34+ Reviewed-by: Manikanta Guntupalli Acked-by: Michal Simek Signed-off-by: Andi Shyti Signed-off-by: Greg Kroah-Hartman

i2c: isch: Add missed 'else'

2024-11-08T15:19:10+00:00

commit 1db4da55070d6a2754efeb3743f5312fc32f5961 upstream. In accordance with the existing comment and code analysis it is quite likely that there is a missed 'else' when adapter times out. Add it. Fixes: 5bc1200852c3 ("i2c: Add Intel SCH SMBus support") Signed-off-by: Andy Shevchenko Cc: # v2.6.27+ Signed-off-by: Andi Shyti Signed-off-by: Greg Kroah-Hartman

i2c: aspeed: Update the stop sw state when the bus recovery occurs

2024-11-08T15:19:10+00:00

commit 93701d3b84ac5f3ea07259d4ced405c53d757985 upstream. When the i2c bus recovery occurs, driver will send i2c stop command in the scl low condition. In this case the sw state will still keep original situation. Under multi-master usage, i2c bus recovery will be called when i2c transfer timeout occurs. Update the stop command calling with aspeed_i2c_do_stop function to update master_state. Fixes: f327c686d3ba ("i2c: aspeed: added driver for Aspeed I2C") Cc: stable@vger.kernel.org # v4.13+ Signed-off-by: Tommy Huang Signed-off-by: Andi Shyti Signed-off-by: Greg Kroah-Hartman

i2c: riic: avoid potential division by zero

2024-09-04T11:13:00+00:00

[ Upstream commit 7890fce6201aed46d3576e3d641f9ee5c1f0e16f ] Value comes from DT, so it could be 0. Unlikely, but could be. Signed-off-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: smbus: Send alert notifications to all devices if source not found

2024-08-19T03:32:14+00:00

[ Upstream commit f6c29f710c1ff2590109f83be3e212b86c01e0f3 ] If a SMBus alert is received and the originating device is not found, the reason may be that the address reported on the SMBus alert address is corrupted, for example because multiple devices asserted alert and do not correctly implement SMBus arbitration. If this happens, call alert handlers on all devices connected to the given I2C bus, in the hope that this cleans up the situation. This change reliably fixed the problem on a system with multiple devices on a single bus. Example log where the device on address 0x18 (ADM1021) and on address 0x4c (ADT7461A) both had the alert line asserted: smbus_alert 3-000c: SMBALERT# from dev 0x0c, flag 0 smbus_alert 3-000c: no driver alert()! smbus_alert 3-000c: SMBALERT# from dev 0x0c, flag 0 smbus_alert 3-000c: no driver alert()! lm90 3-0018: temp1 out of range, please check! lm90 3-0018: Disabling ALERT# lm90 3-0029: Everything OK lm90 3-002a: Everything OK lm90 3-004c: temp1 out of range, please check! lm90 3-004c: temp2 out of range, please check! lm90 3-004c: Disabling ALERT# Fixes: b5527a7766f0 ("i2c: Add SMBus alert support") Signed-off-by: Guenter Roeck [wsa: fixed a typo in the commit message] Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin

i2c: smbus: Improve handling of stuck alerts

2024-08-19T03:32:14+00:00

[ Upstream commit 37c526f00bc1c4f847fc800085f8f009d2e11be6 ] The following messages were observed while testing alert functionality on systems with multiple I2C devices on a single bus if alert was active on more than one chip. smbus_alert 3-000c: SMBALERT# from dev 0x0c, flag 0 smbus_alert 3-000c: no driver alert()! and: smbus_alert 3-000c: SMBALERT# from dev 0x28, flag 0 Once it starts, this message repeats forever at high rate. There is no device at any of the reported addresses. Analysis shows that this is seen if multiple devices have the alert pin active. Apparently some devices do not support SMBus arbitration correctly. They keep sending address bits after detecting an address collision and handle the collision not at all or too late. Specifically, address 0x0c is seen with ADT7461A at address 0x4c and ADM1021 at address 0x18 if alert is active on both chips. Address 0x28 is seen with ADT7483 at address 0x2a and ADT7461 at address 0x4c if alert is active on both chips. Once the system is in bad state (alert is set by more than one chip), it often only recovers by power cycling. To reduce the impact of this problem, abort the endless loop in smbus_alert() if the same address is read more than once and not handled by a driver. Fixes: b5527a7766f0 ("i2c: Add SMBus alert support") Signed-off-by: Guenter Roeck [wsa: it also fixed an interrupt storm in one of my experiments] Tested-by: Wolfram Sang [wsa: rebased, moved a comment as well, improved the 'invalid' value] Signed-off-by: Wolfram Sang Stable-dep-of: f6c29f710c1f ("i2c: smbus: Send alert notifications to all devices if source not found") Signed-off-by: Sasha Levin

i2c: smbus: Don't filter out duplicate alerts

2024-08-19T03:32:13+00:00

[ Upstream commit dca0dd28fa5e0a1ec41a623dbaf667601fc62331 ] Getting the same alert twice in a row is legal and normal, especially on a fast device (like running in qemu). Kind of like interrupts. So don't report duplicate alerts, and deliver them normally. [JD: Fixed subject] Signed-off-by: Corey Minyard Signed-off-by: Jean Delvare Reviewed-by: Benjamin Tissoires Signed-off-by: Wolfram Sang Stable-dep-of: f6c29f710c1f ("i2c: smbus: Send alert notifications to all devices if source not found") Signed-off-by: Sasha Levin

i2c: rcar: bring hardware to known state when probing

2024-07-18T09:39:39+00:00

[ Upstream commit 4e36c0f20cb1c74c7bd7ea31ba432c1c4a989031 ] When probing, the hardware is not brought into a known state. This may be a problem when a hypervisor restarts Linux without resetting the hardware, leaving an old state running. Make sure the hardware gets initialized, especially interrupts should be cleared and disabled. Reported-by: Dirk Behme Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/r/20240702045535.2000393-1-dirk.behme@de.bosch.com Fixes: 6ccbe607132b ("i2c: add Renesas R-Car I2C driver") Signed-off-by: Wolfram Sang Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin

i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr

2024-07-18T09:39:36+00:00

[ Upstream commit f63b94be6942ba82c55343e196bd09b53227618e ] When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from wait_for_completion() after a timeout so replacing the call with wait_for_completion_timeout() allows to remove the problematic timer and its related functions altogether. Fixes: 41561f28e76a ("i2c: New Philips PNX bus driver") Signed-off-by: Piotr Wojtaszczyk Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin