[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6d3d2dfd-4d44-c91a-2145-bae624926259@traphandler.com>
Date: Fri, 7 Oct 2022 08:34:23 +0200
From: Jean-Jacques Hiblot <jjhiblot@...phandler.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
CC: <pavel@....cz>, <robh+dt@...nel.org>,
<sven.schwermer@...ruptive-technologies.com>,
<krzysztof.kozlowski+dt@...aro.org>, <johan+linaro@...nel.org>,
<marijn.suijten@...ainline.org>, <bjorn.andersson@...aro.org>,
<linux-leds@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <sha@...gutronix.de>
Subject: Re: [RESEND PATCH v3 4/4] leds: Add a multicolor LED driver to group
monochromatic LEDs
On 17/09/2022 10:37, Andy Shevchenko wrote:
> On Sat, Sep 17, 2022 at 11:14 AM Jean-Jacques Hiblot
> <jjhiblot@...phandler.com> 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.
> ...
>
>> +config LEDS_GRP_MULTICOLOR
>> + tristate "Multi-color LED grouping support"
>> + help
>> + This option enables support for monochrome LEDs that are
>> + grouped into multicolor LEDs.
> What will be the module name in case of "m" choice?
>
> ...
>
>> + struct led_mcg_priv *priv =
>> + container_of(mc_cdev, struct led_mcg_priv, mc_cdev);
> One line?
>
> ...
>
>> + /*
>> + * Scale the intensity according the max brightness of the
>> + * monochromatic LED
> Usually we put a grammar period at the end of sentences in multi-line comments.
>
>> + */
> ...
>
>> + actual_led_brightness = DIV_ROUND_CLOSEST(
>> + mono->max_brightness * mc_cdev->subled_info[i].brightness,
>> + mc_cdev->led_cdev.max_brightness);
> Can you fix an indentation, so it won't leave the line ending by open
> parenthesis? I believe with the help of a temporary variable it can be
> easily achieved.
Could be done but I have no good name for the variable and I think it
would just make things harder to understand. In that form I think it is
clear that this is a cross-multiplication.
>
> ...
>
>> + for (;;) {
>> + struct led_classdev *led_cdev;
>> + led_cdev = devm_of_led_get(dev, count);
> Why _of_ variant? Please, make this OF independent since it's
> pretending to cover not only OF-based systems.
This is not OF independent. It could be, but that will wait until
someone needs it. I don't know much about ACPI and have no hardware to
test it on.
I'll add the missingĀ dependency on OF in the Kconfig.
>
>
>> + if (IS_ERR(led_cdev)) {
>> + /* Reached the end of the list ? */
>> + if (PTR_ERR(led_cdev) == -ENOENT)
>> + break;
> Looks like the above needs an _optional() variant
>
>> + return dev_err_probe(dev, PTR_ERR(led_cdev),
>> + "Unable to get led #%d", count);
>> + }
> ...
>
>> + priv->monochromatics = devm_krealloc(dev, priv->monochromatics,
>> + count * sizeof(*priv->monochromatics),
>> + GFP_KERNEL);
> This needs at minimum to use one of the helpers from overflow.h,
> ideally you may implement devm_krealloc_array() as a suitable wrapper
> for that.
>
>> + if (!priv->monochromatics)
>> + return -ENOMEM;
> ...
>
>> + subled = devm_kzalloc(dev, count * sizeof(*subled), GFP_KERNEL);
> NIH devm_kcalloc()
>
>> + if (!subled)
>> + return -ENOMEM;
> --
> With Best Regards,
> Andy Shevchenko
Powered by blists - more mailing lists