linux-stable.git/drivers/i2c, branch linux-6.11.y

i2c: dev: Fix memory leak when underlying adapter does not support I2C

2024-12-05T12:53:26+00:00

[ Upstream commit 48730a9d04ffccda541602d722d1ff81920a85d8 ]

Early return in i2cdev_ioctl_rdwr() failed to free the memory allocated
by the caller. Move freeing the memory to the function where it has been
allocated to prevent similar leaks in the future.

Fixes: 97ca843f6ad3 ("i2c: dev: Check for I2C_FUNC_I2C before calling i2c_transfer")
Signed-off-by: Igor Pylypiv 
[wsa: replaced '== NULL' with '!']
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c: designware: do not hold SCL low when I2C_DYNAMIC_TAR_UPDATE is not set

2024-11-14T12:21:11+00:00

commit 8de3e97f3d3d62cd9f3067f073e8ac93261597db upstream.

When the Tx FIFO is empty and the last command has no STOP bit
set, the master holds SCL low. If I2C_DYNAMIC_TAR_UPDATE is not
set, BIT(13) MST_ON_HOLD of IC_RAW_INTR_STAT is not enabled,
causing the __i2c_dw_disable() timeout. This is quite similar to
commit 2409205acd3c ("i2c: designware: fix __i2c_dw_disable() in
case master is holding SCL low"). Also check BIT(7)
MST_HOLD_TX_FIFO_EMPTY in IC_STATUS, which is available when
IC_STAT_FOR_CLK_STRETCH is set.

Fixes: 2409205acd3c ("i2c: designware: fix __i2c_dw_disable() in case master is holding SCL low")
Co-developed-by: Xiaowu Ding 
Signed-off-by: Xiaowu Ding 
Co-developed-by: Angus Chen 
Signed-off-by: Angus Chen 
Signed-off-by: Liu Peibao 
Acked-by: Jarkko Nikula 
Signed-off-by: Andi Shyti 
Signed-off-by: Greg Kroah-Hartman

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

2024-10-17T13:26:35+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: synquacer: Deal with optional PCLK correctly

2024-10-10T10:03:47+00:00

commit f2990f8630531a99cad4dc5c44cb2a11ded42492 upstream.

ACPI boot does not provide clocks and regulators, but instead, provides
the PCLK rate directly, and enables the clock in firmware. So deal
gracefully with this.

Fixes: 55750148e559 ("i2c: synquacer: Fix an error handling path in synquacer_i2c_probe()")
Cc: stable@vger.kernel.org # v6.10+
Cc: Andi Shyti 
Cc: Christophe JAILLET 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Andi Shyti 
Signed-off-by: Greg Kroah-Hartman

i2c: designware: fix controller is holding SCL low while ENABLE bit is disabled

2024-10-10T10:03:46+00:00

commit 5d69d5a00f80488ddcb4dee7d1374a0709398178 upstream.

It was observed that issuing the ABORT bit (IC_ENABLE[1]) will not
work when IC_ENABLE is already disabled.

Check if the ENABLE bit (IC_ENABLE[0]) is disabled when the controller
is holding SCL low. If the ENABLE bit is disabled, the software needs
to enable it before trying to issue the ABORT bit. otherwise,
the controller ignores any write to ABORT bit.

These kernel logs show up whenever an I2C transaction is
attempted after this failure.
i2c_designware e95e0000.i2c: timeout waiting for bus ready
i2c_designware e95e0000.i2c: timeout in disabling adapter

The patch fixes the issue where the controller cannot be disabled
while SCL is held low if the ENABLE bit is already disabled.

Fixes: 2409205acd3c ("i2c: designware: fix __i2c_dw_disable() in case master is holding SCL low")
Signed-off-by: Kimriver Liu 
Cc:  # v6.6+
Reviewed-by: Mika Westerberg 
Acked-by: Jarkko Nikula 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Andi Shyti 
Signed-off-by: Greg Kroah-Hartman

i2c: xiic: Fix pm_runtime_set_suspended() with runtime pm enabled

2024-10-10T10:03:46+00:00

commit 0c8d604dea437b69a861479b413d629bc9b3da70 upstream.

It is not valid to call pm_runtime_set_suspended() for devices
with runtime PM enabled because it returns -EAGAIN if it is enabled
already and working. So, call pm_runtime_disable() before to fix it.

Fixes: 36ecbcab84d0 ("i2c: xiic: Implement power management")
Cc:  # v4.6+
Signed-off-by: Jinjie Ruan 
Signed-off-by: Andi Shyti 
Signed-off-by: Greg Kroah-Hartman

i2c: core: Lock address during client device instantiation

2024-10-10T10:03:46+00:00

commit 8d3cefaf659265aa82b0373a563fdb9d16a2b947 upstream.

Krzysztof reported an issue [0] which is caused by parallel attempts to
instantiate the same I2C client device. This can happen if driver
supports auto-detection, but certain devices are also instantiated
explicitly.
The original change isn't actually wrong, it just revealed that I2C core
isn't prepared yet to handle this scenario.
Calls to i2c_new_client_device() can be nested, therefore we can't use a
simple mutex here. Parallel instantiation of devices at different addresses
is ok, so we just have to prevent parallel instantiation at the same address.
We can use a bitmap with one bit per 7-bit I2C client address, and atomic
bit operations to set/check/clear bits.
Now a parallel attempt to instantiate a device at the same address will
result in -EBUSY being returned, avoiding the "sysfs: cannot create duplicate
filename" splash.

Note: This patch version includes small cosmetic changes to the Tested-by
      version, only functional change is that address locking is supported
      for slave addresses too.

[0] https://lore.kernel.org/linux-i2c/9479fe4e-eb0c-407e-84c0-bd60c15baf74@ans.pl/T/#m12706546e8e2414d8f1a0dc61c53393f731685cc

Fixes: caba40ec3531 ("eeprom: at24: Probe for DDR3 thermal sensor in the SPD case")
Cc: stable@vger.kernel.org
Tested-by: Krzysztof Piotr Oledzki 
Signed-off-by: Heiner Kallweit 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

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

2024-10-10T10:03:46+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: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()

2024-10-10T10:03:46+00:00

commit e2c85d85a05f16af2223fcc0195ff50a7938b372 upstream.

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: Greg Kroah-Hartman

i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume

2024-10-10T10:03:46+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