Re: [PATCH] leds: lm3532: propagate enable GPIO errors

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] leds: lm3532: unconditional dev_err() in caller defeats dev_err_probe() log suppression
- [Low] leds: lm3532: commit message description capitalization violation
--

commit 8b48de70c8c717d07cec849b9e0b416a17a8bb23
Author: bui duc phuc <phucduc.bui@gmail.com>

leds: lm3532: propagate enable GPIO errors

This commit modifies the lm3532 driver to check the return value of
devm_gpiod_get_optional() and propagate errors, rather than treating them
as if the GPIO were not present.

> leds: lm3532: propagate enable GPIO errors

[Severity: Low]
This isn't a bug, but does the commit message subject violate the LED
subsystem guidelines? The guidelines require the commit message description
following the subsystem prefix to be capitalized. Should the description
start with a capital letter?

> diff --git a/drivers/leds/leds-lm3532.c b/drivers/leds/leds-lm3532.c
> index b51496910b082..a3bc9680dc4cf 100644
> --- a/drivers/leds/leds-lm3532.c
> +++ b/drivers/leds/leds-lm3532.c
> @@ -560,7 +560,8 @@ static int lm3532_parse_node(struct lm3532_data *priv)
>  	priv->enable_gpio = devm_gpiod_get_optional(&priv->client->dev,
>  						   "enable", GPIOD_OUT_LOW);
>  	if (IS_ERR(priv->enable_gpio))
> -		priv->enable_gpio = NULL;
> +		return dev_err_probe(&priv->client->dev, PTR_ERR(priv->enable_gpio),
> +				     "failed to get enable GPIO\n");

[Severity: Medium]
Will this change result in unconditional error logging during deferred probes
anyway?

When devm_gpiod_get_optional() returns a deferred probe error, dev_err_probe()
correctly suppresses the log message here. However, the caller lm3532_probe()
does not use dev_err_probe() for its return check:

lm3532_probe() {
    ...
    ret = lm3532_parse_node(drvdata);
    if (ret) {
        dev_err(&client->dev, "Failed to parse node\n");
        return ret;
    }
    ...
}

Because the deferred probe error now bubbles up to lm3532_probe(), won't the
caller log a hard error message to the kernel log and negate the suppression
benefit of this patch?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007104915.507801-1-phucduc.bui@gmail.com?part=1