From: Lee Jones <lee@kernel.org>
To: guptarud@gmail.com
Cc: Pavel Machek <pavel@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Linus Walleij <linusw@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
phone-devel@vger.kernel.org
Subject: Re: [PATCH v5 2/3] leds: flash: rt8515: Support single-GPIO flash ICs with vin supply
Date: Thu, 14 May 2026 11:31:35 +0100 [thread overview]
Message-ID: <20260514103135.GI305027@google.com> (raw)
In-Reply-To: <20260503-expressatt_camera_flash-v5-2-95524506a799@gmail.com>
On Sun, 03 May 2026, Rudraksha Gupta via B4 Relay wrote:
> From: Rudraksha Gupta <guptarud@gmail.com>
>
> Extend the RT8515 driver to support flash ICs that use only a single
> GPIO for both flash and torch modes (no separate ENT pin), with an
> optional vin regulator that gates power to the flash IC.
>
> When vin-supply is provided, the driver enables the regulator before
> activating the LED and disables it when turning off.
>
> Make ent-gpios optional. When ent-gpios is absent, the driver uses
> enf-gpios for both flash and torch brightness control.
>
> Assisted-by: Claude:claude-opus-4.6
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
> ---
> drivers/leds/flash/leds-rt8515.c | 130 +++++++++++++++++++++++++++++++--------
> 1 file changed, 105 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/leds/flash/leds-rt8515.c b/drivers/leds/flash/leds-rt8515.c
> index f6b439674c03..4459874e6a6c 100644
> --- a/drivers/leds/flash/leds-rt8515.c
> +++ b/drivers/leds/flash/leds-rt8515.c
> @@ -31,6 +31,7 @@
> #include <linux/platform_device.h>
> #include <linux/property.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/workqueue.h>
>
> #include <media/v4l2-flash-led-class.h>
>
> @@ -52,7 +53,7 @@ struct rt8515 {
> struct regulator *reg;
> struct gpio_desc *enable_torch;
> struct gpio_desc *enable_flash;
> - struct timer_list powerdown_timer;
> + struct delayed_work powerdown_work;
> u32 max_timeout; /* Flash max timeout */
> int flash_max_intensity;
> int torch_max_intensity;
> @@ -63,16 +64,50 @@ static struct rt8515 *to_rt8515(struct led_classdev_flash *fled)
> return container_of(fled, struct rt8515, fled);
> }
>
> -static void rt8515_gpio_led_off(struct rt8515 *rt)
> +static int rt8515_gpio_led_off(struct rt8515 *rt)
> {
> + int ret;
> +
> gpiod_set_value(rt->enable_flash, 0);
> gpiod_set_value(rt->enable_torch, 0);
> +
> + if (!rt->reg)
> + return 0;
> +
> + /* Disable regulator */
This comment is superfluous.
> + ret = regulator_is_enabled(rt->reg);
> + if (ret < 0)
> + return ret;
Initialise ret to 0 and return ret then you can remove this branch.
> + if (ret > 0)
> + return regulator_disable(rt->reg);
> +
> + return 0;
> }
>
> -static void rt8515_gpio_brightness_commit(struct gpio_desc *gpiod,
> - int brightness)
> +static int rt8515_gpio_brightness_commit(struct rt8515 *rt,
> + struct gpio_desc *gpiod,
> + int brightness)
Use 100-chars to avoid this cramping.
> {
> int i;
> + int ret;
> +
> + /*
> + * Reset the IC to start brightness from zero,
> + * then re-enable and pulse to the desired level.
> + */
> + ret = rt8515_gpio_led_off(rt);
> + if (ret)
> + return ret;
> +
> + /* IC needs time to reset its brightness counter */
> + usleep_range(100, 200);
> +
> + /* Enable regulator */
As above.
> + if (rt->reg) {
> + ret = regulator_enable(rt->reg);
> + if (ret)
> + return ret;
> + }
>
> /*
> * Toggling a GPIO line with a small delay increases the
> @@ -84,6 +119,8 @@ static void rt8515_gpio_brightness_commit(struct gpio_desc *gpiod,
> gpiod_set_value(gpiod, 1);
> udelay(1);
> }
> +
> + return 0;
> }
>
> /* This is setting the torch light level */
> @@ -92,23 +129,38 @@ static int rt8515_led_brightness_set(struct led_classdev *led,
> {
> struct led_classdev_flash *fled = lcdev_to_flcdev(led);
> struct rt8515 *rt = to_rt8515(fled);
> + int ret = 0;
>
> mutex_lock(&rt->lock);
>
> if (brightness == LED_OFF) {
> /* Off */
> - rt8515_gpio_led_off(rt);
> + ret = rt8515_gpio_led_off(rt);
> + if (ret)
> + goto out;
> } else if (brightness < RT8515_TORCH_MAX) {
> - /* Step it up to movie mode brightness using the flash pin */
> - rt8515_gpio_brightness_commit(rt->enable_torch, brightness);
> + /*
> + * Step it up to movie mode brightness.
> + * If there is no separate torch pin, use the flash pin
> + * for torch as well.
> + */
> + ret = rt8515_gpio_brightness_commit(rt,
> + rt->enable_torch ?: rt->enable_flash, brightness);
> + if (ret)
> + goto out;
> } else {
> - /* Max torch brightness requested */
> - gpiod_set_value(rt->enable_torch, 1);
> + /*
> + * Max torch brightness requested.
> + * If there is no separate torch pin, use the flash pin
> + * for torch as well.
> + */
> + gpiod_set_value(rt->enable_torch ?: rt->enable_flash, 1);
What does 1 mean in this context? Maybe define it so it's clear.
> }
>
> +out:
> mutex_unlock(&rt->lock);
>
> - return 0;
> + return ret;
> }
>
> static int rt8515_led_flash_strobe_set(struct led_classdev_flash *fled,
> @@ -117,27 +169,34 @@ static int rt8515_led_flash_strobe_set(struct led_classdev_flash *fled,
> struct rt8515 *rt = to_rt8515(fled);
> struct led_flash_setting *timeout = &fled->timeout;
> int brightness = rt->flash_max_intensity;
> + int ret = 0;
>
> mutex_lock(&rt->lock);
>
> if (state) {
> /* Enable LED flash mode and set brightness */
> - rt8515_gpio_brightness_commit(rt->enable_flash, brightness);
> + ret = rt8515_gpio_brightness_commit(rt, rt->enable_flash, brightness);
> + if (ret)
> + goto out;
> +
> /* Set timeout */
> - mod_timer(&rt->powerdown_timer,
> - jiffies + usecs_to_jiffies(timeout->val));
> + schedule_delayed_work(&rt->powerdown_work,
> + usecs_to_jiffies(timeout->val));
> } else {
> - timer_delete_sync(&rt->powerdown_timer);
> + cancel_delayed_work(&rt->powerdown_work);
Would it be safer to use 'cancel_delayed_work_sync()' here? The previous
implementation used the synchronous 'timer_delete_sync()'. Swapping to an
asynchronous cancellation might introduce a race condition if the work is
already executing.
> /* Turn the LED off */
> - rt8515_gpio_led_off(rt);
> + ret = rt8515_gpio_led_off(rt);
> + if (ret)
> + goto out;
> }
>
> fled->led_cdev.brightness = LED_OFF;
> /* After this the torch LED will be disabled */
>
> +out:
> mutex_unlock(&rt->lock);
>
> - return 0;
> + return ret;
> }
>
> static int rt8515_led_flash_strobe_get(struct led_classdev_flash *fled,
> @@ -145,7 +204,7 @@ static int rt8515_led_flash_strobe_get(struct led_classdev_flash *fled,
> {
> struct rt8515 *rt = to_rt8515(fled);
>
> - *state = timer_pending(&rt->powerdown_timer);
> + *state = delayed_work_pending(&rt->powerdown_work);
>
> return 0;
> }
> @@ -163,12 +222,18 @@ static const struct led_flash_ops rt8515_flash_ops = {
> .timeout_set = rt8515_led_flash_timeout_set,
> };
>
> -static void rt8515_powerdown_timer(struct timer_list *t)
> +static void rt8515_powerdown_work(struct work_struct *work)
> {
> - struct rt8515 *rt = timer_container_of(rt, t, powerdown_timer);
> + struct rt8515 *rt = container_of(work, struct rt8515, powerdown_work.work);
> + int ret;
>
> /* Turn the LED off */
> - rt8515_gpio_led_off(rt);
> + mutex_lock(&rt->lock);
> + ret = rt8515_gpio_led_off(rt);
> + mutex_unlock(&rt->lock);
> +
> + if (ret)
> + dev_err(rt->dev, "failed to turn off LED (%d)\n", ret);
> }
>
> static void rt8515_init_flash_timeout(struct rt8515 *rt)
> @@ -298,12 +363,22 @@ static int rt8515_probe(struct platform_device *pdev)
> return dev_err_probe(dev, PTR_ERR(rt->enable_flash),
> "cannot get ENF (enable flash) GPIO\n");
>
> - /* ENT - Enable Torch line */
> - rt->enable_torch = devm_gpiod_get(dev, "ent", GPIOD_OUT_LOW);
> + /* ENT - Enable Torch line (optional for single-GPIO flash ICs) */
> + rt->enable_torch = devm_gpiod_get_optional(dev, "ent", GPIOD_OUT_LOW);
> if (IS_ERR(rt->enable_torch))
> return dev_err_probe(dev, PTR_ERR(rt->enable_torch),
> "cannot get ENT (enable torch) GPIO\n");
The user doesn't care about 'ENT'.
"Failed to obtain the Enable Torch GPIO"
> +
> + /* Optional VIN supply */
Doesn't the function call already say this?
> + rt->reg = devm_regulator_get_optional(dev, "vin");
> + if (IS_ERR(rt->reg)) {
> + ret = PTR_ERR(rt->reg);
> + if (ret != -ENODEV)
> + return dev_err_probe(dev, ret,
> + "failed to get vin supply\n");
Why are we erroring out on an optional regulator?
> + rt->reg = NULL;
> + }
> +
> child = device_get_next_child_node(dev, NULL);
> if (!child) {
> dev_err(dev,
> @@ -328,12 +403,17 @@ static int rt8515_probe(struct platform_device *pdev)
> dev_warn(dev,
> "flash-max-timeout-us property missing\n");
> }
> - timer_setup(&rt->powerdown_timer, rt8515_powerdown_timer, 0);
> + INIT_DELAYED_WORK(&rt->powerdown_work, rt8515_powerdown_work);
> rt8515_init_flash_timeout(rt);
>
> fled->ops = &rt8515_flash_ops;
>
> - led->max_brightness = rt->torch_max_intensity;
> + /*
> + * If there is no separate torch pin, use the flash max intensity
Drop the "the".
> + * as the max brightness instead.
> + */
> + led->max_brightness = rt->enable_torch ?
> + rt->torch_max_intensity : rt->flash_max_intensity;
> led->brightness_set_blocking = rt8515_led_brightness_set;
> led->flags |= LED_CORE_SUSPENDRESUME | LED_DEV_CAP_FLASH;
>
> @@ -372,7 +452,7 @@ static void rt8515_remove(struct platform_device *pdev)
> struct rt8515 *rt = platform_get_drvdata(pdev);
>
> rt8515_v4l2_flash_release(rt);
> - timer_delete_sync(&rt->powerdown_timer);
> + cancel_delayed_work_sync(&rt->powerdown_work);
> mutex_destroy(&rt->lock);
> }
>
>
> --
> 2.54.0
>
>
--
Lee Jones
next prev parent reply other threads:[~2026-05-14 10:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-03 21:43 [PATCH v5 0/3] Samsung Expressatt: Camera Flash Rudraksha Gupta
2026-05-03 21:43 ` Rudraksha Gupta via B4 Relay
2026-05-03 21:43 ` [PATCH v5 1/3] dt-bindings: leds: rt8515: Support single-GPIO flash ICs with vin supply Rudraksha Gupta
2026-05-03 21:43 ` Rudraksha Gupta via B4 Relay
2026-05-03 21:43 ` [PATCH v5 2/3] leds: flash: " Rudraksha Gupta
2026-05-03 21:43 ` Rudraksha Gupta via B4 Relay
2026-05-14 10:31 ` Lee Jones [this message]
2026-05-03 21:43 ` [PATCH v5 3/3] ARM: dts: qcom: msm8960: expressatt: Add camera flash Rudraksha Gupta
2026-05-03 21:43 ` Rudraksha Gupta via B4 Relay
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=20260514103135.GI305027@google.com \
--to=lee@kernel.org \
--cc=andersson@kernel.org \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=guptarud@gmail.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linusw@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@kernel.org \
--cc=phone-devel@vger.kernel.org \
--cc=robh@kernel.org \
/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.