kernel/linux.git/drivers/i2c, branch linux-7.1.y

i2c: imx-lpi2c: fix resource leaks switching to devm_dma_request_chan()

2026-06-09T08:13:09+00:00

The LPI2C driver requests DMA channels using dma_request_chan(), but never releases them in lpi2c_imx_remove(), resulting in DMA channel leaks every time the driver is unloaded. Additionally, when lpi2c_dma_init() successfully requests the TX DMA channel but fails to request the RX DMA channel, the probe falls back to PIO mode and completes successfully. Since probe succeeds, the devres framework will not trigger any cleanup, leaving the TX DMA channel and the memory allocated for the dma structure held for the lifetime of the device even though DMA is never used. Switch to devm_dma_request_chan() to let the device core manage DMA channel lifetime automatically. Wrap all allocations within a devres group so that devres_release_group() can release all partially acquired resources when DMA init fails and probe continues in PIO mode. Fixes: a09c8b3f9047 ("i2c: imx-lpi2c: add eDMA mode support for LPI2C") Signed-off-by: Carlos Song Cc: # v6.14+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260520093323.2882070-1-carlos.song@oss.nxp.com

i2c: tegra: Fix NOIRQ suspend/resume

2026-06-08T19:21:42+00:00

The Tegra I2C driver relies on runtime PM to wake up the controller before each transfer. However, runtime PM is disabled between the system suspend and NOIRQ suspend. If an I2C device initiates a transfer during this window, the I2C controller fails to wake up and the transfer fails. To handle this, the controller must be kept available for this period to allow transfers. Rework the I2C controller's system PM callbacks such that the controller is resumed from runtime suspend during system suspend and it stays RPM_ACTIVE throughout the suspend-resume cycle until it is runtime suspended back in the system resume. The clocks are disabled in NOIRQ suspend and enabled back in NOIRQ resume by calling the controller's runtime PM functions directly. Fixes: 8ebf15e9c869 ("i2c: tegra: Move suspend handling to NOIRQ phase") Assisted-by: Cursor:claude-4.6-opus Signed-off-by: Akhil R Cc: # v5.4+ Reviewed-by: Jon Hunter Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260518114013.62065-5-akhilrajeev@nvidia.com

i2c: tegra: Update Tegra410 I2C timing parameters

2026-06-08T19:21:35+00:00

Update Tegra410 I2C timing parameters based on hardware characterization results. This adjusts the fast mode and HS mode settings to be compliant with the I2C specification. Fixes: 59717f260183 ("i2c: tegra: Add support for Tegra410") Signed-off-by: Akhil R Reviewed-by: Jon Hunter Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260518114013.62065-4-akhilrajeev@nvidia.com

i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()

2026-06-08T18:31:46+00:00

On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] .... Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver") Signed-off-by: Vladimir Zapolskiy Cc: # v5.8+ Reviewed-by: Konrad Dybcio Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260515234121.1607425-2-vladimir.zapolskiy@linaro.org

i2c: stm32f7: fix timing computation ignoring i2c-analog-filter

2026-06-08T17:56:04+00:00

stm32f7_i2c_compute_timing() uses i2c_dev->analog_filter to pick the analog filter delay, but i2c_dev->analog_filter is parsed from the "i2c-analog-filter" DT property only after the compute_timing loop in stm32f7_i2c_setup_timing(), so in practice the timing calculations always ignore the analog filter. On an STM32MP1 board with clock-frequency = <400000> and i2c-analog-filter set, measured SCL frequency was ~382 kHz. This also affects (widens) the computed SDADEL range. At high bus clock speeds, this can select an SDADEL value that violates tVD;DAT (data valid time). Fix by parsing "i2c-analog-filter" before the compute_timing loop. Fixes: 83c3408f7b9c ("i2c: stm32f7: support DT binding i2c-analog-filter") Signed-off-by: Guillermo Rodríguez Cc: # v5.13+ Acked-by: Alain Volmat Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260526091210.20383-1-guille.rodriguez@gmail.com

i2c: imx: fix clock and pinctrl state inconsistency in runtime PM

2026-06-08T17:43:05+00:00

In i2c_imx_runtime_suspend(), the clock is disabled before switching the pinctrl state to sleep. If pinctrl_pm_select_sleep_state() fails, the runtime suspend is aborted but the clock remains disabled, causing a system crash when the hardware is subsequently accessed. Fix this by switching the pinctrl state before disabling the clock so that a pinctrl failure leaves the clock enabled and the hardware accessible. In i2c_imx_runtime_resume(), restore the pinctrl state back to sleep if clk_enable() fails to keep the consistent. Fixes: 576eba03c994 ("i2c: imx: switch different pinctrl state in different system power status") Signed-off-by: Carlos Song Cc: # v6.14+ Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260521065038.2954998-1-carlos.song@oss.nxp.com

i2c: riic: fix refcount leak in riic_i2c_resume_noirq()

2026-06-08T15:35:03+00:00

When riic_i2c_resume_noirq() is called, it deasserts the reset using reset_control_deassert(), which for shared resets increments a reference count. If pm_runtime_force_resume() then fails, the function returns without calling reset_control_assert() to decrement the count. This leaves the reset deasserted and the reference count unbalanced, which can prevent other users of the shared reset from properly asserting it later. Fix the leak by calling reset_control_assert() on the error handling path for a failed pm_runtime_force_resume(). Fixes: e383f0961422 ("i2c: riic: Move suspend handling to NOIRQ phase") Signed-off-by: Wentao Liang Cc: # v6.19+ Reviewed-by: Geert Uytterhoeven Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260608071123.128964-1-vulab@iscas.ac.cn

i2c: virtio: mark device ready before registering the adapter

2026-05-30T13:56:07+00:00

virtio_i2c_probe() synchronously probes child i2c drivers on the bus, but peripherals may use the bus at probe for tasks like reading a chip id. The vhost-user-i2c backend stalls at such probes unless DRIVER_OK is already set before the virtqueue is first kicked. Set DRIVER_OK explicitly before i2c_add_adapter(), as done for the same reason in commit f5866db64f34 ("virtio_console: enable VQs early") and commit 71e4b8bf0482 ("virtio_rpmsg: set DRIVER_OK before using device"). Signed-off-by: Alexis Bouzigues Signed-off-by: Wolfram Sang

i2c: davinci: fix division by zero on missing clock-frequency

2026-05-26T23:07:05+00:00

When the 'clock-frequency' property is missing from the device tree, the driver falls back to DAVINCI_I2C_DEFAULT_BUS_FREQ. However, this macro was defined in kHz (100), whereas the device tree property is expected in Hz. The probe function divided the fallback value by 1000, causing integer truncation that resulted in dev->bus_freq = 0. This triggered a deterministic division-by-zero kernel panic when calculating clock dividers later in the probe sequence. Fix this by redefining DAVINCI_I2C_DEFAULT_BUS_FREQ in Hz (100000) to match the expected device tree property unit, allowing the existing division logic to work correctly for both cases. Fixes: b04ce6385979 ("i2c: davinci: kill platform data") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260514044726.57297C2BCB7@smtp.kernel.org/ Signed-off-by: Chaitanya Sabnis Cc: # v6.14+ Reviewed-by: Bartosz Golaszewski Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260526102240.4949-1-chaitanya.msabnis@gmail.com

i2c: smbus: fix a potential uninitialization bug

2026-05-19T10:43:08+00:00

In i2c_smbus_xfer_emulated(), there are two buffers: msgbuf0 and msgbuf1, which are used to save a series of messages, as mentioned in the comment. According to the value of the variable 'size', msgbuf0 is initialized to various values. In contrast, msgbuf1 is left uninitialized until the function i2c_transfer() is invoked. However, msgbuf1 is not always initialized on all possible execution paths (implementation) of i2c_transfer(). Thus, it is possible that msgbuf1 may still be uninitialized even after the invocation of the function i2c_transfer(), especially when the return value of i2c_transfer() is not checked properly. In the following execution, the uninitialized msgbuf1 will be used, such as for security checks. Since uninitialized values can be random and arbitrary, this will cause undefined behaviors or even check bypass. For example, it is expected that if the value of 'size' is I2C_SMBUS_BLOCK_PROC_CALL, the value of data->block[0] should not be larger than I2C_SMBUS_BLOCK_MAX. This patch initializes the first byte of msgbuf1 with 0 to avoid such undefined behaviors or security issues. Signed-off-by: Wenwen Wang [wsa: reworded commit message a little] Signed-off-by: Wolfram Sang