On Wed, Dec 28, 2022 at 2:41 AM Andy Shevchenko
<andy.shevchenko@xxxxxxxxx> wrote:
> On Tue, Dec 27, 2022 at 12:07 PM Jean-Jacques Hiblot
> <jjhiblot@xxxxxxxxxxxxxxx> wrote:
> >
> > By allowing to group multiple monochrome LED into multicolor LEDs,
> > all involved LEDs can be controlled in-sync. This enables using effects
> > using triggers, etc.
>
> ...
>
> > + count = 0;
> > + max_brightness = 0;
> > + for (;;) {
> > + struct led_classdev *led_cdev;
> > +
> > + led_cdev = devm_of_led_get_optional(dev, count);
>
> > +
>
> Redundant blank line.
>
> > + if (IS_ERR(led_cdev))
> > + return dev_err_probe(dev, PTR_ERR(led_cdev),
> > + "Unable to get led #%d", count);
> > +
> > + /* Reached the end of the list ?*/
> > + if (!led_cdev)
> > + break;
>
> > + count++;
>
> If I understand the flow correctly, this can be moved...
>
> > + priv->monochromatics = devm_krealloc_array(dev, priv->monochromatics,
> > + count, sizeof(*priv->monochromatics),
Yes, here the + 1 will be needed instead. But I think it would be
better from the reader perspective, as we try to allocate memory for
existing amount + 1 as it would be clearly written.
> > + GFP_KERNEL);
> > + if (!priv->monochromatics)
> > + return -ENOMEM;
>
> > + priv->monochromatics[count - 1] = led_cdev;
>
> ...here either as a separate line or a part of the above assignment,
> in either case the -1 wouldn't be needed.
>
>
> > + max_brightness = max(max_brightness, led_cdev->max_brightness);
> > + }
P.S. Bjorn's address is wrong.
--
With Best Regards,
Andy Shevchenko
