[PATCH] leds: rgb: leds-ktd202x: Fix error code in ktd202x_setup_led_rgb()

[PATCH] leds: rgb: leds-ktd202x: Fix error code in ktd202x_setup_led_rgb()

[Dan Carpenter]

Return -EINVAL if the "reg" value is invalid.  This is unlikely to
happen in real life because it comes from the firmware, whether from
device tree or ACPI.

Fixes: f14aa5ea415b ("leds: rgb: leds-ktd202x: Get device properties through fwnode to support ACPI")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
 drivers/leds/rgb/leds-ktd202x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/rgb/leds-ktd202x.c b/drivers/leds/rgb/leds-ktd202x.c
index e4f0f25a5e45..3b7f2272036c 100644
--- a/drivers/leds/rgb/leds-ktd202x.c
+++ b/drivers/leds/rgb/leds-ktd202x.c
@@ -410,7 +410,7 @@ static int ktd202x_setup_led_rgb(struct ktd202x *chip, struct fwnode_handle *fwn
 		if (ret != 0 || reg >= chip->num_leds) {
 			dev_err(chip->dev, "invalid 'reg' of %pfw\n", child);
 			fwnode_handle_put(child);
-			return ret;
+			return ret ?: -EINVAL;
 		}
 
 		ret = fwnode_property_read_u32(child, "color", &mono_color);
-- 
2.51.0

Re: [PATCH] leds: rgb: leds-ktd202x: Fix error code in ktd202x_setup_led_rgb()

[Andy Shevchenko]

On Tue, Dec 9, 2025 at 8:56 AM Dan Carpenter <dan.carpenter@linaro.org> wrote:
>
> Return -EINVAL if the "reg" value is invalid.  This is unlikely to
> happen in real life because it comes from the firmware, whether from
> device tree or ACPI.

...

>                 if (ret != 0 || reg >= chip->num_leds) {
>                         dev_err(chip->dev, "invalid 'reg' of %pfw\n", child);
>                         fwnode_handle_put(child);
> -                       return ret;
> +                       return ret ?: -EINVAL;
>                 }

I think the better fix is to split the original conditional to two.

And make the message something like
"can't retrieve 'reg' property of %pfw\n'
for the case if (ret).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] leds: rgb: leds-ktd202x: Fix error code in ktd202x_setup_led_rgb()

[Dan Carpenter]

On Tue, Dec 09, 2025 at 04:14:03PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 9, 2025 at 8:56 AM Dan Carpenter <dan.carpenter@linaro.org> wrote:
> >
> > Return -EINVAL if the "reg" value is invalid.  This is unlikely to
> > happen in real life because it comes from the firmware, whether from
> > device tree or ACPI.
> 
> ...
> 
> >                 if (ret != 0 || reg >= chip->num_leds) {
> >                         dev_err(chip->dev, "invalid 'reg' of %pfw\n", child);
> >                         fwnode_handle_put(child);
> > -                       return ret;
> > +                       return ret ?: -EINVAL;
> >                 }
> 
> I think the better fix is to split the original conditional to two.
> 
> And make the message something like
> "can't retrieve 'reg' property of %pfw\n'
> for the case if (ret).
> 

These are never going to show up for users, the messages are only for
developers bringing up a board...

regards,
dan carpenter

Re: [PATCH] leds: rgb: leds-ktd202x: Fix error code in ktd202x_setup_led_rgb()

[Andy Shevchenko]

On Tue, Dec 9, 2025 at 4:41 PM Dan Carpenter <dan.carpenter@linaro.org> wrote:
> On Tue, Dec 09, 2025 at 04:14:03PM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 9, 2025 at 8:56 AM Dan Carpenter <dan.carpenter@linaro.org> wrote:

...

> > >                 if (ret != 0 || reg >= chip->num_leds) {
> > >                         dev_err(chip->dev, "invalid 'reg' of %pfw\n", child);
> > >                         fwnode_handle_put(child);
> > > -                       return ret;
> > > +                       return ret ?: -EINVAL;
> > >                 }
> >
> > I think the better fix is to split the original conditional to two.
> >
> > And make the message something like
> > "can't retrieve 'reg' property of %pfw\n'
> > for the case if (ret).
>
> These are never going to show up for users, the messages are only for
> developers bringing up a board...

Even better,

  if (ret) {
    fwnode_handle_put(...);
    return ret;
  }

  if (reg >= ...) {
    ...
  }

Since it's a fix likely for a backporting, the separate change can
move to the _scoped() for_each loop and drop those fwnode_handle_put()
calls.

-- 
With Best Regards,
Andy Shevchenko