mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Myeonghun Pak <mhun512@gmail.com>,
	Sylvain Petinot <sylvain.petinot@foss.st.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	<linux-media@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<stable@vger.kernel.org>
Subject: Re: [PATCH v2] media: i2c: vd56g3: clean up subdev state on probe failure
Date: Fri, 19 Jun 2026 10:59:24 +0200	[thread overview]
Message-ID: <02b07f43-3c90-4e89-8747-7fd424d87dd1@foss.st.com> (raw)
In-Reply-To: <ajPcKcJfbIdPKI8-@kekkonen.localdomain>

Hi Sakari,

Le 18/06/2026 à 13:53, Sakari Ailus a écrit :
> Hi Benjamin,
> 
> On Tue, Jun 16, 2026 at 02:49:54PM +0200, Benjamin Mugnier wrote:
>> Hi,
>>
>> Thank you for your patch, and apologies for the delay.
>>
>> Le 24/04/2026 à 18:52, Myeonghun Pak a écrit :
>>> vd56g3_subdev_init() calls v4l2_subdev_init_finalize(), which allocates
>>> the subdev active state and requires v4l2_subdev_cleanup() to release it.
>>>
>>> If vd56g3_update_controls() fails after finalize succeeds, the probe error
>>> path currently skips v4l2_subdev_cleanup() and returns an error. The driver
>>> .remove() callback is not called after a failed probe, so the active state
>>> is leaked.
>>>
>>> Route this error through a subdev cleanup label before freeing the control
>>> handler and media entity.
>>>
>>> Fixes: 87aa97fc3157 ("media: i2c: Add driver for ST VD56G3 camera sensor")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
>>> ---
>>> Changes in v2:
>>> - Use a lowercase subject summary.
>>
>> Please keep the first character uppercase, just like other commits on
>> this module.
>>
>>>
>>>  drivers/media/i2c/vd56g3.c | 5 ++++-
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/media/i2c/vd56g3.c b/drivers/media/i2c/vd56g3.c
>>> index 157acea9e2..43f792288a 100644
>>> --- a/drivers/media/i2c/vd56g3.c
>>> +++ b/drivers/media/i2c/vd56g3.c
>>> @@ -1427,11 +1427,14 @@ static int vd56g3_subdev_init(struct vd56g3 *sensor)
>>>  	v4l2_subdev_unlock_state(state);
>>>  	if (ret) {
>>>  		dev_err(sensor->dev, "Controls update failed: %d\n", ret);
>>> -		goto err_ctrls;
>>> +		goto err_subdev;
>>>  	}
>>>  
>>>  	return 0;
>>>  
>>> +err_subdev:
>>> +	v4l2_subdev_cleanup(&sensor->sd);
>>
>> v4l2_subdev_cleanup() is already performed in the caller (i.e.
>> vd56g3_probe()), but as you noticed it is not called from this path. I'd
>> rather have the return value route correctly through
>> v4l2_subdev_cleanup() in  vd56g3_probe(), allowing to keep a unique call
>> to v4l2_subdev_cleanup() instead.
> 
> Is it?
> 
> If vd56g3_update_controls() in vd56g3_subdev_init() fails, it'll jump to
> err_power_off in vd56g3_probe() which does PM related cleanup only.
> 

Exactly, I realize my sentence was poorly written, but if I understand
correctly we're on the same page. The problem being
v4l2_subdev_cleanup() not being called in any path if
vd56g3_update_controls() fails.

Now if vd56g3_update_controls() fails, instead of performing
v4l2_subdev_cleanup() in vd56g3_subdev_init() as this patch does, I'd
rather have it done in vd56g3_probe()'s jump back so we can keep it all
at the same place, instead of having 2 v4l2_subdev_cleanup() in 2
different places.

Tell me if this is still unclear.

>>
>> This patch looks like is LLM generated and sparks my curiosity. If so
>> you must disclaim it using an Assisted-by tag [1]. Sorry if I’m mistaken.
>>
>> [1] https://docs.kernel.org/process/coding-assistants.html
>>
>>> +
>>>  err_ctrls:
>>>  	v4l2_ctrl_handler_free(sensor->sd.ctrl_handler);
>>>  
>>
>> -- 
>> Regards,
>> Benjamin
>>
> 

-- 
Regards,
Benjamin


  reply	other threads:[~2026-06-19  8:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-24 16:52 Myeonghun Pak
2026-06-16 12:49 ` Benjamin Mugnier
2026-06-18 11:53   ` Sakari Ailus
2026-06-19  8:59     ` Benjamin Mugnier [this message]
2026-06-22 12:00       ` Myeonghun Pak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02b07f43-3c90-4e89-8747-7fd424d87dd1@foss.st.com \
    --to=benjamin.mugnier@foss.st.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mhun512@gmail.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=stable@vger.kernel.org \
    --cc=sylvain.petinot@foss.st.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®