[PATCH 0/3] i2c: fix DMA channel leaks on probe error and remove

[PATCH 0/3] i2c: fix DMA channel leaks on probe error and remove

[Shengzhuo Wei]

Three I2C bus drivers request exclusive DMA channels before
registering their adapter, but none of them releases the channels on
the probe error path (the remove callback is not invoked after a
failed probe), and the at91 driver never releases them on remove
either. Same class as 777979e62711 ("i2c: mxs: fix DMA channel leak on
probe error"), which used devm_dma_request_chan() for mxs; here the
drivers own non-devm state, so the fixes release the channels
explicitly on the error paths.

The three drivers are otherwise unrelated; the series exists only
because the bug shape and the fix shape are identical.

---
Shengzhuo Wei (3):
      i2c: at91: release DMA channels on remove and probe error
      i2c: imx: release DMA channels on probe error
      i2c: qcom-geni: release DMA channels on probe error

 drivers/i2c/busses/i2c-at91-core.c   |  3 +++
 drivers/i2c/busses/i2c-at91-master.c | 12 +++++++++++-
 drivers/i2c/busses/i2c-at91.h        |  1 +
 drivers/i2c/busses/i2c-imx.c         |  2 ++
 drivers/i2c/busses/i2c-qcom-geni.c   |  4 +++-
 5 files changed, 20 insertions(+), 2 deletions(-)
---
base-commit: 45c13f3f9e3bb15fd89ff2864c6f627a3b4b4229
change-id: 20260827-i2c-dma-channel-leak-b58522243736

Best regards,
--  
Shengzhuo Wei <me@cherr.cc>

[PATCH 1/3] i2c: at91: release DMA channels on remove and probe error

[Shengzhuo Wei]

at91_twi_configure_dma() requests exclusive tx/rx DMA channels, but
nothing ever releases them on driver detach, and the probe error path
after the channels are acquired (i2c_add_numbered_adapter() failure)
returns without releasing them either, because the remove callback is
not invoked after a failed probe.

Move the release into a helper, call it from the existing
configure-failure path, the adapter-registration failure path, and
at91_twi_remove().

Fixes: 60937b2cdbf9 ("i2c: at91: add dma support")
Cc: stable@vger.kernel.org
Signed-off-by: Shengzhuo Wei <me@cherr.cc>
Assisted-by: GLM:5.3
---
 drivers/i2c/busses/i2c-at91-core.c   |  3 +++
 drivers/i2c/busses/i2c-at91-master.c | 12 +++++++++++-
 drivers/i2c/busses/i2c-at91.h        |  1 +
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-at91-core.c b/drivers/i2c/busses/i2c-at91-core.c
index b64adef778d4..8ca4556d9664 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -255,6 +255,7 @@ static int at91_twi_probe(struct platform_device *pdev)
 	if (rc) {
 		pm_runtime_disable(dev->dev);
 		pm_runtime_set_suspended(dev->dev);
+		at91_twi_dma_release(dev);
 
 		return rc;
 	}
@@ -270,6 +271,8 @@ static void at91_twi_remove(struct platform_device *pdev)
 
 	i2c_del_adapter(&dev->adapter);
 
+	at91_twi_dma_release(dev);
+
 	pm_runtime_disable(dev->dev);
 	pm_runtime_set_suspended(dev->dev);
 }
diff --git a/drivers/i2c/busses/i2c-at91-master.c b/drivers/i2c/busses/i2c-at91-master.c
index 894cedbca99f..68238cc8aee0 100644
--- a/drivers/i2c/busses/i2c-at91-master.c
+++ b/drivers/i2c/busses/i2c-at91-master.c
@@ -817,11 +817,21 @@ static int at91_twi_configure_dma(struct at91_twi_dev *dev, u32 phy_addr)
 error:
 	if (ret != -EPROBE_DEFER)
 		dev_info(dev->dev, "can't get DMA channel, continue without DMA support\n");
+	at91_twi_dma_release(dev);
+	return ret;
+}
+
+void at91_twi_dma_release(struct at91_twi_dev *dev)
+{
+	struct at91_twi_dma *dma = &dev->dma;
+
 	if (dma->chan_rx)
 		dma_release_channel(dma->chan_rx);
 	if (dma->chan_tx)
 		dma_release_channel(dma->chan_tx);
-	return ret;
+	dma->chan_rx = NULL;
+	dma->chan_tx = NULL;
+	dev->use_dma = false;
 }
 
 static int at91_init_twi_recovery_gpio(struct platform_device *pdev,
diff --git a/drivers/i2c/busses/i2c-at91.h b/drivers/i2c/busses/i2c-at91.h
index 942e9c3973bb..d68fcbbc3e0f 100644
--- a/drivers/i2c/busses/i2c-at91.h
+++ b/drivers/i2c/busses/i2c-at91.h
@@ -172,6 +172,7 @@ void at91_twi_irq_restore(struct at91_twi_dev *dev);
 void at91_init_twi_bus(struct at91_twi_dev *dev);
 
 void at91_init_twi_bus_master(struct at91_twi_dev *dev);
+void at91_twi_dma_release(struct at91_twi_dev *dev);
 int at91_twi_probe_master(struct platform_device *pdev, u32 phy_addr,
 			  struct at91_twi_dev *dev);
 

-- 
2.47.3

[PATCH 2/3] i2c: imx: release DMA channels on probe error

[Shengzhuo Wei]

i2c_imx_dma_request() acquires exclusive tx/rx DMA channels and is
optional: on errors other than -EPROBE_DEFER the driver falls back to
PIO mode and probe continues. If i2c_add_numbered_adapter() then fails,
probe returns through clk_notifier_unregister without releasing the
channels, because the remove callback is not invoked after a failed
probe.

Release the channels on the probe error path, mirroring
i2c_imx_remove().

Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
Cc: stable@vger.kernel.org
Signed-off-by: Shengzhuo Wei <me@cherr.cc>
Assisted-by: GLM:5.3
---
 drivers/i2c/busses/i2c-imx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 19ec056b00af..c24d9201a60e 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1880,6 +1880,8 @@ static int i2c_imx_probe(struct platform_device *pdev)
 
 clk_notifier_unregister:
 	clk_notifier_unregister(i2c_imx->clk, &i2c_imx->clk_change_nb);
+	if (i2c_imx->dma)
+		i2c_imx_dma_free(i2c_imx);
 	free_irq(irq, i2c_imx);
 rpm_disable:
 	pm_runtime_put_noidle(&pdev->dev);

-- 
2.47.3

[PATCH 3/3] i2c: qcom-geni: release DMA channels on probe error

[Shengzhuo Wei]

geni_i2c_init() grabs exclusive GPI tx/rx DMA channels when the serial
engine runs in GPI mode. If i2c_add_adapter() subsequently fails, probe
returns without releasing the channels, because the remove callback is
not invoked after a failed probe.

The adapter-registration failure path used to release the channels via
its err_dma label; that release was dropped when the probe tail was
restructured into geni_i2c_init().

Release the channels on the adapter-registration failure path, mirroring
geni_i2c_remove().

Fixes: d8d3bb127ad1 ("i2c: qcom-geni: Isolate serial engine setup")
Cc: stable@vger.kernel.org
Signed-off-by: Shengzhuo Wei <me@cherr.cc>
Assisted-by: GLM:5.3
---
 drivers/i2c/busses/i2c-qcom-geni.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
index 658636c1ee0e..45c770552bd2 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -1189,8 +1189,10 @@ static int geni_i2c_probe(struct platform_device *pdev)
 		return ret;
 
 	ret = i2c_add_adapter(&gi2c->adap);
-	if (ret)
+	if (ret) {
+		release_gpi_dma(gi2c);
 		return dev_err_probe(dev, ret, "Error adding i2c adapter\n");
+	}
 
 	dev_dbg(dev, "Geni-I2C adaptor successfully added\n");
 

-- 
2.47.3

Re: [PATCH 1/3] i2c: at91: release DMA channels on remove and probe error

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] DMA channels requested by at91_twi_configure_dma() are leaked if bus recovery initialization returns -EPROBE_DEFER.
- [High] Zero-length I2C messages (e.g., SMBus Quick) unconditionally fail with -ENOMEM when DMA is enabled, violating I2C core DMA contracts.
- [High] Unbalanced clk_disable_unprepare() on driver unbind due to devm_clk_get_enabled() and PM runtime suspend.
--

commit 6d740b54bf5767e2505374ef8cd5b48bd70b0cc4
Author: Shengzhuo Wei <me@cherr.cc>

i2c: at91: release DMA channels on remove and probe error

This commit moves the DMA channel release logic into a new helper function
at91_twi_dma_release(). It calls this helper during driver removal and on
the adapter registration failure path to prevent DMA channels from leaking.

> diff --git a/drivers/i2c/busses/i2c-at91-core.c b/drivers/i2c/busses/i2c-at91-core.c
> index b64adef778d4b..8ca4556d96649 100644
> --- a/drivers/i2c/busses/i2c-at91-core.c
> +++ b/drivers/i2c/busses/i2c-at91-core.c
> @@ -255,6 +255,7 @@ static int at91_twi_probe(struct platform_device *pdev)
>  	if (rc) {
>  		pm_runtime_disable(dev->dev);
>  		pm_runtime_set_suspended(dev->dev);
> +		at91_twi_dma_release(dev);
>  
>  		return rc;
>  	}

[Severity: High]
This isn't a bug introduced by this patch, but does this code also leak DMA
channels if an error occurs earlier in probe?

If at91_init_twi_recovery_info() returns -EPROBE_DEFER (e.g. waiting for
pinctrl), at91_twi_probe_master() propagates the error to at91_twi_probe(),
which returns early:

drivers/i2c/busses/i2c-at91-core.c:at91_twi_probe() {
    ...
    if (dev->slave_detected)
        rc = at91_twi_probe_slave(pdev, phy_addr, dev);
    else
        rc = at91_twi_probe_master(pdev, phy_addr, dev);
    if (rc)
        return rc;
    ...
}

Since at91_twi_probe_master() acquires the DMA channels via
at91_twi_configure_dma() before calling at91_init_twi_recovery_info(),
does returning here without calling at91_twi_dma_release() cause a resource
leak of DMA channels?

> @@ -270,6 +271,8 @@ static void at91_twi_remove(struct platform_device *pdev)
>  
>  	i2c_del_adapter(&dev->adapter);
>  
> +	at91_twi_dma_release(dev);
> +
>  	pm_runtime_disable(dev->dev);
>  	pm_runtime_set_suspended(dev->dev);

[Severity: High]
This is a pre-existing issue, but can this removal sequence cause a clock
enable count underflow?

The probe function calls devm_clk_get_enabled(), which registers a devres
action to call clk_disable_unprepare() on removal. The PM runtime suspend
callback at91_twi_runtime_suspend() also disables the clock.

In at91_twi_remove(), there is no pm_runtime_get_sync() before
pm_runtime_disable(). If the device is runtime-suspended during unbind, the
clock is already physically disabled. When remove() returns, does the devres
action fire and call clk_disable_unprepare() a second time, leading to a
kernel WARN and potential clock tree corruption?

>  }
> diff --git a/drivers/i2c/busses/i2c-at91-master.c b/drivers/i2c/busses/i2c-at91-master.c
> index 894cedbca99f5..68238cc8aee0d 100644
> --- a/drivers/i2c/busses/i2c-at91-master.c
> +++ b/drivers/i2c/busses/i2c-at91-master.c
[ ... ]
> @@ -817,11 +817,21 @@ static int at91_twi_configure_dma(struct at91_twi_dev *dev, u32 phy_addr)
>  error:
>  	if (ret != -EPROBE_DEFER)
>  		dev_info(dev->dev, "can't get DMA channel, continue without DMA support\n");
> +	at91_twi_dma_release(dev);
> +	return ret;
> +}
> +
> +void at91_twi_dma_release(struct at91_twi_dev *dev)
> +{
> +	struct at91_twi_dma *dma = &dev->dma;
> +
>  	if (dma->chan_rx)
>  		dma_release_channel(dma->chan_rx);
>  	if (dma->chan_tx)
>  		dma_release_channel(dma->chan_tx);
> -	return ret;
> +	dma->chan_rx = NULL;
> +	dma->chan_tx = NULL;
> +	dev->use_dma = false;
>  }

[Severity: High]
This isn't a bug introduced by this patch, but does enabling DMA cause
zero-length I2C messages (like SMBus Quick) to unconditionally fail with
-ENOMEM?

When dev->use_dma is true and a zero-length message is submitted,
i2c_get_dma_safe_msg_buf() correctly returns NULL according to its API
contract (as the length is below the threshold of 1). However, the driver
checks this in at91_twi_xfer() and returns -ENOMEM:

drivers/i2c/busses/i2c-at91-master.c:at91_twi_xfer() {
    ...
    dma_buf = i2c_get_dma_safe_msg_buf(m_start, 1);
    if (!dma_buf) {
        ret = -ENOMEM;
        goto out;
    }
    ...
}

Does this break zero-length I2C transfers by aborting them instead of
gracefully falling back to PIO?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827-i2c-dma-channel-leak-v1-0-271d4adc03a0@cherr.cc?part=1

Re: [PATCH 2/3] i2c: imx: release DMA channels on probe error

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The IRQ handler accesses hardware registers without verifying if the device is runtime active, and the runtime suspend callback lacks `synchronize_irq()`. This combination causes system crashes or invalid reads on shared IRQ lines.
--

commit bd798c45679ae67bd4a370c03b96a207ed6bc4a9
Author: Shengzhuo Wei <me@cherr.cc>

i2c: imx: release DMA channels on probe error

i2c_imx_dma_request() acquires exclusive tx/rx DMA channels and is optional.
If i2c_add_numbered_adapter() then fails, probe returns without releasing
the channels. This commit ensures the channels are released on the probe
error path.

Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
Cc: stable@vger.kernel.org

> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 19ec056b00afe..c24d9201a60e8 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1880,6 +1880,8 @@ static int i2c_imx_probe(struct platform_device *pdev)
>  
>  clk_notifier_unregister:
>  	clk_notifier_unregister(i2c_imx->clk, &i2c_imx->clk_change_nb);
> +	if (i2c_imx->dma)
> +		i2c_imx_dma_free(i2c_imx);
>  	free_irq(irq, i2c_imx);

[Severity: High]
This isn't a bug introduced by this patch, but since we're modifying the
probe and IRQ cleanup paths, could this driver crash due to unclocked
register reads if the IRQ is shared?

Looking at the driver, the IRQ is registered as shared during probe:

drivers/i2c/busses/i2c-imx.c:i2c_imx_probe() {
    ...
    ret = request_irq(irq, i2c_imx_isr, IRQF_SHARED | IRQF_NO_SUSPEND,
                      pdev->name, i2c_imx);
    ...
}

However, the runtime suspend callback disables the clock without ensuring
no ISR is running:

drivers/i2c/busses/i2c-imx.c:i2c_imx_runtime_suspend() {
    ...
    clk_disable(i2c_imx->clk);
    ...
}

If another device sharing the same interrupt line fires while this device
is runtime suspended, i2c_imx_isr() is called and unconditionally reads from
the unclocked hardware:

drivers/i2c/busses/i2c-imx.c:i2c_imx_isr() {
    ...
    status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
    ...
}

Should the runtime suspend callback use synchronize_irq(), and the ISR use
pm_runtime_get_if_active() before accessing hardware registers to prevent
these invalid reads or system crashes?

>  rpm_disable:
>  	pm_runtime_put_noidle(&pdev->dev);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827-i2c-dma-channel-leak-v1-0-271d4adc03a0@cherr.cc?part=2

Re: [PATCH 3/3] i2c: qcom-geni: release DMA channels on probe error

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:

Pre-existing issues:
- [High] Double Free / Use-After-Free in `geni_i2c_gpi_xfer` due to stale `rx_buf`/`tx_buf` pointers.
- [High] Double free in `geni_i2c_tx_one_msg` and `geni_i2c_rx_one_msg` when DMA preparation fails.
- [High] Multi-descriptor transfer arrays `dma_buf` and `dma_addr` are leaked on early error paths.
- [High] Probe failure leaves the device in `RPM_ACTIVE` state, permanently leaking clocks and interconnect bandwidth.
- [Medium] Unprotected state modification of `gi2c->err` on timeout in GPI transfer mode.
--

commit c5e9b3033c37b684962141040cbfbb6d92768687
Author: Shengzhuo Wei <me@cherr.cc>

i2c: qcom-geni: release DMA channels on probe error

This commit ensures that exclusive GPI tx/rx DMA channels are properly
released if the I2C adapter registration fails during probe. Previously,
the function returned without freeing these channels.

> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
> index 658636c1ee0e2..45c770552bd26 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -1189,8 +1189,10 @@ static int geni_i2c_probe(struct platform_device *pdev)
>  		return ret;
>  
>  	ret = i2c_add_adapter(&gi2c->adap);
> -	if (ret)
> +	if (ret) {
> +		release_gpi_dma(gi2c);
>  		return dev_err_probe(dev, ret, "Error adding i2c adapter\n");
> +	}

[Severity: High]
This isn't a bug introduced by this patch, but does failing the probe here
without forcefully suspending the device leave it locked in the RPM_ACTIVE
state indefinitely?

Since the device is configured for autosuspend earlier in geni_i2c_probe(),
returning an error here triggers devres cleanup. This cleanup cancels the
pending autosuspend timer. Because the usage count is 0 but the device is
still physically active, could this permanently leak power, clocks, and
interconnect bandwidth?

>  
>  	dev_dbg(dev, "Geni-I2C adaptor successfully added\n");

While reviewing this patch, I also noticed a few other pre-existing issues in
the driver.

[Severity: High]
This is a pre-existing issue, but does geni_i2c_gpi_xfer() double-free the
buffer when processing mixed read/write I2C messages?

drivers/i2c/busses/i2c-qcom-geni.c:geni_i2c_gpi_xfer() {
        ...
		if (!gi2c->is_tx_multi_desc_xfer)
			geni_i2c_gpi_unmap(gi2c, &msgs[i], tx_buf, tx_addr, rx_buf, rx_addr);
        ...
}

If a batch contains a read message (which allocates and assigns rx_buf) followed
by a write-only message, the second iteration bypasses the read DMA setup.
Since rx_buf and tx_buf are declared outside the loop and not reset to NULL
between iterations, does geni_i2c_gpi_unmap() end up passing the stale rx_buf
from the previous message, causing i2c_put_dma_safe_msg_buf() to double-free it?

Similarly, on the error path in the same function:

drivers/i2c/busses/i2c-qcom-geni.c:geni_i2c_gpi_xfer() {
        ...
	else
		geni_i2c_gpi_unmap(gi2c, &msgs[i], tx_buf, tx_addr, rx_buf, rx_addr);
        ...
}

Are the same stale buffer pointers unconditionally passed here on failure,
causing a double free?


[Severity: High]
This is a pre-existing issue, but does a DMA preparation failure lead to a
double free in geni_i2c_tx_msg_cleanup()?

drivers/i2c/busses/i2c-qcom-geni.c:geni_i2c_tx_one_msg() {
        ...
	} else {
		gi2c->xfer_len = len;
		gi2c->dma_addr = tx_dma;
		gi2c->dma_buf = dma_buf;
	}
        ...
}

When geni_se_tx_dma_prep() fails, this else block is bypassed. Could this leave
gi2c->dma_buf retaining a stale pointer from the previous I2C message?

drivers/i2c/busses/i2c-qcom-geni.c:geni_i2c_tx_msg_cleanup() {
        ...
		i2c_put_dma_safe_msg_buf(gi2c->dma_buf, cur, !gi2c->err);
        ...
}

When this cleanup function is subsequently called, will it unconditionally pass
the stale, non-NULL pointer from the previous message to be freed again?


[Severity: High]
This is a pre-existing issue, but are the multi-descriptor transfer arrays
leaked on early error paths?

drivers/i2c/busses/i2c-qcom-geni.c:geni_i2c_gpi_multi_desc_unmap() {
        ...
		if (tx_multi_xfer->unmap_msg_cnt == gi2c->num_msgs - 1) {
			kfree(tx_multi_xfer->dma_buf);
			kfree(tx_multi_xfer->dma_addr);
			break;
		}
        ...
}

If an early error occurs (such as DMA mapping failing on the first message) and
the code jumps to the error label, the loop bound is lower than the required
threshold. Will gating the kfree() calls behind this final message index check
cause dma_buf and dma_addr to be permanently leaked?


[Severity: Medium]
This is a pre-existing issue, but is there a data race when modifying the error
state on timeout?

drivers/i2c/busses/i2c-qcom-geni.c:geni_i2c_gpi_xfer() {
        ...
				gi2c->err = -ETIMEDOUT;
        ...
}

In GPI transfer mode, this error state is updated directly on timeout without
holding gi2c->lock.

drivers/i2c/busses/i2c-qcom-geni.c:i2c_gpi_cb_result() {
        ...
		gi2c->err = -EIO;
        ...
}

If the DMA transaction completes with an error precisely as the timeout expires,
could the interrupt handler concurrently modify gi2c->err, leading to a race
that corrupts the logged or returned error code?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827-i2c-dma-channel-leak-v1-0-271d4adc03a0@cherr.cc?part=3

Re: [PATCH 2/3] i2c: imx: release DMA channels on probe error

[Frank Li]

On Thu, Aug 27, 2026 at 11:43:02PM +0800, Shengzhuo Wei wrote:
> i2c_imx_dma_request() acquires exclusive tx/rx DMA channels and is
> optional: on errors other than -EPROBE_DEFER the driver falls back to
> PIO mode and probe continues. If i2c_add_numbered_adapter() then fails,
> probe returns through clk_notifier_unregister without releasing the
> channels, because the remove callback is not invoked after a failed
> probe.
>
> Release the channels on the probe error path, mirroring
> i2c_imx_remove().
>
> Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shengzhuo Wei <me@cherr.cc>
> Assisted-by: GLM:5.3

Nit: signed-off-by should be last tag

Reviewed-by: Frank Li <Frank.Li@nxp.com>

> ---
>  drivers/i2c/busses/i2c-imx.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 19ec056b00af..c24d9201a60e 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1880,6 +1880,8 @@ static int i2c_imx_probe(struct platform_device *pdev)
>
>  clk_notifier_unregister:
>  	clk_notifier_unregister(i2c_imx->clk, &i2c_imx->clk_change_nb);
> +	if (i2c_imx->dma)
> +		i2c_imx_dma_free(i2c_imx);
>  	free_irq(irq, i2c_imx);
>  rpm_disable:
>  	pm_runtime_put_noidle(&pdev->dev);
>
> --
> 2.47.3
>

Re: [PATCH 3/3] i2c: qcom-geni: release DMA channels on probe error

[Konrad Dybcio]

On 8/27/26 5:43 PM, Shengzhuo Wei wrote:
> geni_i2c_init() grabs exclusive GPI tx/rx DMA channels when the serial
> engine runs in GPI mode. If i2c_add_adapter() subsequently fails, probe
> returns without releasing the channels, because the remove callback is
> not invoked after a failed probe.
> 
> The adapter-registration failure path used to release the channels via
> its err_dma label; that release was dropped when the probe tail was
> restructured into geni_i2c_init().
> 
> Release the channels on the adapter-registration failure path, mirroring
> geni_i2c_remove().
> 
> Fixes: d8d3bb127ad1 ("i2c: qcom-geni: Isolate serial engine setup")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shengzhuo Wei <me@cherr.cc>
> Assisted-by: GLM:5.3
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH 3/3] i2c: qcom-geni: release DMA channels on probe error

[Mukesh Savaliya]

On 8/27/2026 9:13 PM, Shengzhuo Wei wrote:
> geni_i2c_init() grabs exclusive GPI tx/rx DMA channels when the serial
> engine runs in GPI mode. If i2c_add_adapter() subsequently fails, probe
> returns without releasing the channels, because the remove callback is
> not invoked after a failed probe.
> 
> The adapter-registration failure path used to release the channels via
> its err_dma label; that release was dropped when the probe tail was
> restructured into geni_i2c_init().
> 
> Release the channels on the adapter-registration failure path, mirroring
> geni_i2c_remove().
> 
> Fixes: d8d3bb127ad1 ("i2c: qcom-geni: Isolate serial engine setup")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shengzhuo Wei <me@cherr.cc>
> Assisted-by: GLM:5.3
> ---

Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>

Re: [PATCH 1/3] i2c: at91: release DMA channels on remove and probe error

[Mukesh Savaliya]

On 8/27/2026 9:13 PM, Shengzhuo Wei wrote:
> at91_twi_configure_dma() requests exclusive tx/rx DMA channels, but
> nothing ever releases them on driver detach, and the probe error path
> after the channels are acquired (i2c_add_numbered_adapter() failure)
> returns without releasing them either, because the remove callback is
> not invoked after a failed probe.
> 
> Move the release into a helper, call it from the existing
> configure-failure path, the adapter-registration failure path, and
> at91_twi_remove().
> 
> Fixes: 60937b2cdbf9 ("i2c: at91: add dma support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shengzhuo Wei <me@cherr.cc>
> Assisted-by: GLM:5.3
> ---
Acked-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>