All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "George Neacsu" <geocausa@gmail.com>
Cc: linux-leds@vger.kernel.org, lee@kernel.org
Subject: Re: [PATCH] leds: flash: leds-qcom-flash: Release all V4L2 flash devices
Date: Fri, 16 Oct 2026 06:44:29 +0000	[thread overview]
Message-ID: <sashiko-outbox-173877@kernel.org> (raw)
In-Reply-To: <20261016-qcom-flash-v4l2-release-v1-1-0e92aa7c9327@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] leds: missing mutex_destroy() on probe error paths
--

commit 02e8e6631f1731424fa6ad18e025af7434984559
Author: George Neacsu <geocausa@gmail.com>

leds: flash: leds-qcom-flash: Release all V4L2 flash devices

This commit fixes an out-of-bounds array access and a loop logic error
during probe failure and driver removal. It ensures all registered V4L2
flash sub-devices are correctly released.

> diff --git a/drivers/leds/flash/leds-qcom-flash.c b/drivers/leds/flash/leds-qcom-flash.c
> index b03a6833e3e3a..c2fefeec9b80c 100644
> --- a/drivers/leds/flash/leds-qcom-flash.c
> +++ b/drivers/leds/flash/leds-qcom-flash.c
> @@ -953,8 +953,8 @@ static int qcom_flash_led_probe(struct platform_device *pdev)
>  
>  	return regmap_field_write(flash_data->r_fields[REG_TORCH_CLAMP], flash_data->torch_clamp);
>  release:
> -	while (flash_data->v4l2_flash[flash_data->leds_count] && flash_data->leds_count)
> -		v4l2_flash_release(flash_data->v4l2_flash[flash_data->leds_count--]);
> +	while (flash_data->leds_count)
> +		v4l2_flash_release(flash_data->v4l2_flash[--flash_data->leds_count]);

[Severity: Low]
Are we missing a call to mutex_destroy() for flash_data->lock on the error
paths?

Earlier in qcom_flash_led_probe(), the driver calls
mutex_init(&flash_data->lock). However, neither this release cleanup block
nor the earlier direct error returns destroy it:

	count = device_get_child_node_count(dev);
	if (count == 0 || count > flash_data->max_channels) {
		dev_err(dev, "No child or child count exceeds %d\n", ...);
		return -EINVAL;
	}

While the memory for flash_data is devres-managed, bypassing mutex_destroy()
omits CONFIG_DEBUG_MUTEXES validation hooks during teardown and leaves the
cleanup asymmetric compared to qcom_flash_led_remove().

>  	return rc;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-qcom-flash-v4l2-release-v1-1-0e92aa7c9327@gmail.com?part=1

      reply	other threads:[~2026-10-16  6:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16  6:37 [PATCH] leds: flash: leds-qcom-flash: Release all V4L2 flash devices George Neacsu via B4 Relay
2026-10-16  6:37 ` George Neacsu
2026-10-16  6:44 ` sashiko-bot [this message]

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=sashiko-outbox-173877@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=geocausa@gmail.com \
    --cc=lee@kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.