From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

The driver allcoates memory using kzalloc_obj() and frees it in the relase
path. since the allocated memory is tied to the lifetime of the device,
devm_kzalloc() can be used instead.

Using device-managed allocation simplifies the error handling paths and
remove the need for manual cleanup.

No functional change intended.

Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
Changes in v2:
 - Rebase on tip of latest tip
 - Updated commit message accordingly.
 - Link to v1 https://lore.kernel.org/all/20260307210404.1428894-1-sanjayembedded@gmail.com/
---
 drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
index b442dcba02e7..bd4b5f08a85c 100644
--- a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
+++ b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
@@ -2200,14 +2200,12 @@ static int mxc_jpeg_open(struct file *file)
 	struct mxc_jpeg_ctx *ctx;
 	int ret = 0;
 
-	ctx = kzalloc_obj(*ctx);
+	ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
 	if (!ctx)
 		return -ENOMEM;
 
-	if (mutex_lock_interruptible(&mxc_jpeg->lock)) {
-		ret = -ERESTARTSYS;
-		goto free;
-	}
+	if (mutex_lock_interruptible(&mxc_jpeg->lock))
+		return -ERESTARTSYS;
 
 	v4l2_fh_init(&ctx->fh, mxc_vfd);
 	v4l2_fh_add(&ctx->fh, file);
@@ -2246,8 +2244,6 @@ static int mxc_jpeg_open(struct file *file)
 	v4l2_fh_del(&ctx->fh, file);
 	v4l2_fh_exit(&ctx->fh);
 	mutex_unlock(&mxc_jpeg->lock);
-free:
-	kfree(ctx);
 	return ret;
 }
 
@@ -2754,7 +2750,6 @@ static int mxc_jpeg_release(struct file *file)
 	v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
 	v4l2_fh_del(&ctx->fh, file);
 	v4l2_fh_exit(&ctx->fh);
-	kfree(ctx);
 	mutex_unlock(&mxc_jpeg->lock);
 
 	return 0;
-- 
2.34.1

On 08.03.2026 11:35:54, Sanjay Chitroda wrote:
> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>
> The driver allcoates memory using kzalloc_obj() and frees it in the relase
> path. since the allocated memory is tied to the lifetime of the device,
> devm_kzalloc() can be used instead.

What happens if you issue multiple open()/close() cycles per device
lifetime? Will the memory pile up, until the mxc_jpeg_remove() function
is called?

> Using device-managed allocation simplifies the error handling paths and
> remove the need for manual cleanup.
>
> No functional change intended.

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

On 9 March 2026 9:23:57 pm IST, Marc Kleine-Budde <mkl@blackshift.org> wrote:
>On 08.03.2026 11:35:54, Sanjay Chitroda wrote:
>> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>>
>> The driver allcoates memory using kzalloc_obj() and frees it in the relase
>> path. since the allocated memory is tied to the lifetime of the device,
>> devm_kzalloc() can be used instead.
>
>What happens if you issue multiple open()/close() cycles per device
>lifetime? Will the memory pile up, until the mxc_jpeg_remove() function
>is called?

You are correct.

Since the context structure is allocated in .open() and released in
.release(), its lifetime is tied to the file handle rather than the
device.

Using devm_kzalloc() would defer freeing the memory until device
removal, which could cause memory accumulation across multiple
open()/close() cycles.

I'll drop this change.

>
>> Using device-managed allocation simplifies the error handling paths and
>> remove the need for manual cleanup.
>>
>> No functional change intended.
>
>Marc
>