linux-stable.git/drivers/i2c, branch v5.4.285

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

2024-11-08T15:20:44+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: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()

2024-11-08T15:20:42+00:00

[ Upstream commit e2c85d85a05f16af2223fcc0195ff50a7938b372 ]

disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable when request IRQ.

Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller")
Signed-off-by: Jinjie Ruan 
Cc:  # v4.19+
Acked-by: Mukesh Kumar Savaliya 
Reviewed-by: Vladimir Zapolskiy 
Signed-off-by: Andi Shyti 
Signed-off-by: Sasha Levin

i2c: qcom-geni: Grow a dev pointer to simplify code

2024-11-08T15:20:42+00:00

[ Upstream commit 3b7d81f08a6a2bdd406df4355b08d39def8104aa ]

Some lines are long here. Use a struct dev pointer to shorten lines and
simplify code. The clk_get() call can fail because of EPROBE_DEFER
problems too, so just remove the error print message because it isn't
useful. Finally, platform_get_irq() already prints an error so just
remove that error message.

Reviewed-by: Douglas Anderson 
Reviewed-by: Brendan Higgins 
Signed-off-by: Stephen Boyd 
Reviewed-by: Bjorn Andersson 
Reviewed-by: Amit Kucheria 
Signed-off-by: Wolfram Sang 
Stable-dep-of: e2c85d85a05f ("i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()")
Signed-off-by: Sasha Levin

i2c: qcom-geni: Let firmware specify irq trigger flags

2024-11-08T15:20:42+00:00

[ Upstream commit b2ca8800621b95ecced081376de9fe256b1fa479 ]

We don't need to force IRQF_TRIGGER_HIGH here as the DT or ACPI tables
should take care of this for us. Just use 0 instead so that we use the
flags from the firmware. Also, remove specify dev_name() for the irq
name so that we can get better information in /proc/interrupts about
which device is generating interrupts.

Cc: Alok Chauhan 
Reviewed-by: Douglas Anderson 
Reviewed-by: Brendan Higgins 
Signed-off-by: Stephen Boyd 
Reviewed-by: Bjorn Andersson 
Reviewed-by: Amit Kucheria 
Signed-off-by: Wolfram Sang 
Stable-dep-of: e2c85d85a05f ("i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()")
Signed-off-by: Sasha Levin

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

2024-11-08T15:20:39+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: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume

2024-11-08T15:20:39+00:00

commit 048bbbdbf85e5e00258dfb12f5e368f908801d7b upstream.

In case there is any sort of clock controller attached to this I2C bus
controller, for example Versaclock or even an AIC32x4 I2C codec, then
an I2C transfer triggered from the clock controller clk_ops .prepare
callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.

This is because the clock controller first grabs the prepare_lock mutex
and then performs the prepare operation, including its I2C access. The
I2C access resumes this I2C bus controller via .runtime_resume callback,
which calls clk_prepare_enable(), which attempts to grab the prepare_lock
mutex again and deadlocks.

Since the clock are already prepared since probe() and unprepared in
remove(), use simple clk_enable()/clk_disable() calls to enable and
disable the clock on runtime suspend and resume, to avoid hitting the
prepare_lock mutex.

Acked-by: Alain Volmat 
Signed-off-by: Marek Vasut 
Fixes: 4e7bca6fc07b ("i2c: i2c-stm32f7: add PM Runtime support")
Cc:  # v5.0+
Signed-off-by: Andi Shyti 
Signed-off-by: Greg Kroah-Hartman

i2c: isch: Add missed 'else'

2024-11-08T15:20:35+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:20:35+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:14:53+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:33:50+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