linux-stable.git/drivers/i2c, branch v6.6.53

i2c: stm32f7: Add atomic_xfer method to driver

2024-08-29T15:33:42+00:00

commit 470a662688563d8f5e0fb164930d6f5507a883e4 upstream.

Add an atomic_xfer method to the driver so that it behaves correctly
when controlling a PMIC that is responsible for device shutdown.

The atomic_xfer method added is similar to the one from the i2c-mv64xxx
driver. When running an atomic_xfer a bool flag in the driver data is
set, the interrupt is not unmasked on transfer start, and the IRQ
handler is manually invoked while waiting for pending transfers to
complete.

Signed-off-by: Sean Nyekjaer 
Acked-by: Andi Shyti 
Signed-off-by: Wolfram Sang 
Cc: Christoph Niedermaier 
Signed-off-by: Greg Kroah-Hartman

i2c: riic: avoid potential division by zero

2024-08-29T15:33:24+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: qcom-geni: Add missing geni_icc_disable in geni_i2c_runtime_resume

2024-08-29T15:33:14+00:00

commit 4e91fa1ef3ce6290b4c598e54b5eb6cf134fbec8 upstream.

Add the missing geni_icc_disable() call before returning in the
geni_i2c_runtime_resume() function.

Commit 9ba48db9f77c ("i2c: qcom-geni: Add missing
geni_icc_disable in geni_i2c_runtime_resume") by Gaosheng missed
disabling the interconnect in one case.

Fixes: bf225ed357c6 ("i2c: i2c-qcom-geni: Add interconnect support")
Cc: Gaosheng Cui 
Cc: stable@vger.kernel.org # v5.9+
Signed-off-by: Andi Shyti 
Signed-off-by: Greg Kroah-Hartman

i2c: tegra: Do not mark ACPI devices as irq safe

2024-08-29T15:33:12+00:00

commit 14d069d92951a3e150c0a81f2ca3b93e54da913b upstream.

On ACPI machines, the tegra i2c module encounters an issue due to a
mutex being called inside a spinlock. This leads to the following bug:

	BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585
	...

	Call trace:
	__might_sleep
	__mutex_lock_common
	mutex_lock_nested
	acpi_subsys_runtime_resume
	rpm_resume
	tegra_i2c_xfer

The problem arises because during __pm_runtime_resume(), the spinlock
&dev->power.lock is acquired before rpm_resume() is called. Later,
rpm_resume() invokes acpi_subsys_runtime_resume(), which relies on
mutexes, triggering the error.

To address this issue, devices on ACPI are now marked as not IRQ-safe,
considering the dependency of acpi_subsys_runtime_resume() on mutexes.

Fixes: bd2fdedbf2ba ("i2c: tegra: Add the ACPI support")
Cc:  # v5.17+
Co-developed-by: Michael van der Westhuizen 
Signed-off-by: Michael van der Westhuizen 
Signed-off-by: Breno Leitao 
Reviewed-by: Dmitry Osipenko 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Andi Shyti 
Signed-off-by: Greg Kroah-Hartman

i2c: qcom-geni: Add missing geni_icc_disable in geni_i2c_runtime_resume

2024-08-14T11:58:52+00:00

[ Upstream commit 9ba48db9f77ce0001dbb882476fa46e092feb695 ]

Add the missing geni_icc_disable() before return in
geni_i2c_runtime_resume().

Fixes: bf225ed357c6 ("i2c: i2c-qcom-geni: Add interconnect support")
Signed-off-by: Gaosheng Cui 
Reviewed-by: Vladimir Zapolskiy 
Signed-off-by: Andi Shyti 
Signed-off-by: Sasha Levin

i2c: qcom-geni: Add missing clk_disable_unprepare in geni_i2c_runtime_resume

2024-08-14T11:58:52+00:00

[ Upstream commit b93d16bee557302d4e588375ececd833cc048acc ]

Add the missing clk_disable_unprepare() before return in
geni_i2c_runtime_resume().

Fixes: 14d02fbadb5d ("i2c: qcom-geni: add desc struct to prepare support for I2C Master Hub variant")
Signed-off-by: Gaosheng Cui 
Reviewed-by: Vladimir Zapolskiy 
Signed-off-by: Andi Shyti 
Signed-off-by: Sasha Levin

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

2024-08-14T11:58:51+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-14T11:58:50+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 
Signed-off-by: Sasha Levin

i2c: rcar: fix error code in probe()

2024-07-18T11:21:27+00:00

commit 37a672be3ae357a0f87fbc00897fa7fcb3d7d782 upstream.

Return an error code if devm_reset_control_get_exclusive() fails.
The current code returns success.

Fixes: 0e864b552b23 ("i2c: rcar: reset controller is mandatory for Gen3+")
Signed-off-by: Dan Carpenter 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: rcar: clear NO_RXDMA flag after resetting

2024-07-18T11:21:26+00:00

[ Upstream commit fea6b5ebb71a2830b042e42de7ae255017ac3ce8 ]

We should allow RXDMA only if the reset was really successful, so clear
the flag after the reset call.

Fixes: 0e864b552b23 ("i2c: rcar: reset controller is mandatory for Gen3+")
Signed-off-by: Wolfram Sang 
Signed-off-by: Andi Shyti 
Signed-off-by: Sasha Levin