| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <310ce737-df38-766c-b24a-17c26c5f9ab6@gmail.com>
Date: Wed, 31 Jul 2019 21:45:05 +0200
From: Jacek Anaszewski <jacek.anaszewski@...il.com>
To: Dan Murphy <dmurphy@...com>, pavel@....cz
Cc: linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 9/9] leds: Update the lp55xx to use the multi color
framework
Dan,
On 7/31/19 8:55 PM, Dan Murphy wrote:
> Jacek
>
> Thanks for looking
You're welcome.
> On 7/31/19 1:45 PM, Jacek Anaszewski wrote:
>> Hi Dan,
>>
>> Thank you for the patch. My comments are below.
>>
>> On 7/25/19 8:28 PM, Dan Murphy wrote:
>>> Update the lp5523 to use the multi color framework.
>>>
>>> Signed-off-by: Dan Murphy <dmurphy@...com>
>>> ---
>>> drivers/leds/leds-lp5523.c | 13 ++
>>> drivers/leds/leds-lp55xx-common.c | 153 ++++++++++++++++++----
>>> drivers/leds/leds-lp55xx-common.h | 10 ++
>>> include/linux/platform_data/leds-lp55xx.h | 6 +
>>> modules.builtin.modinfo | Bin 0 -> 43550 bytes
>>> 5 files changed, 159 insertions(+), 23 deletions(-)
>>> create mode 100644 modules.builtin.modinfo
>>>
>>> diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
>>> index d0b931a136b9..45380b32563f 100644
>>> --- a/drivers/leds/leds-lp5523.c
>>> +++ b/drivers/leds/leds-lp5523.c
[...]
>
>>> + if (ret)
>>> + break;
>>> + }
>>> + } else {
>>> + led->brightness = (u8)brightness;
>> What benefit stems actually from having the copy of brightness
>> in struct lp55xx_led, when we already have struct led_classdev
>> there? I know that this is pre-existing, but could be optimized away
>> while at it. We can have local u8 variable in the op setting brightness
>> and cast enum_led_brightness to it before passing to lp55xx_write().
>>
> This was a carry over from the original driver. Ln 140.
>
> I am not looking to change existing code functionality.
>
> First pass was just to introduce mc_fw with no disruption or regression
>
> to the base functionality.
Sure thing. Just wanted to mention that for a record.
[...]
>>> - led->cdev.brightness_set_blocking = lp55xx_set_brightness;
>>> - led->cdev.groups = lp55xx_led_groups;
>>> -
>>> - if (pdata->led_config[chan].name) {
>>> - led->cdev.name = pdata->led_config[chan].name;
>>> - } else {
>>> - snprintf(name, sizeof(name), "%s:channel%d",
>>> - pdata->label ? : chip->cl->name, chan);
>>> - led->cdev.name = name;
>>> - }
>>> + if (pdata->led_config[chan].num_colors > 1)
>>> + ret = led_classdev_multicolor_register(dev, &led->mc_cdev);
>>> + else
>>> + ret = led_classdev_register(dev, &led->cdev);
>> Why not devm ?
>
> I will call the devm_ for multicolor but conversion for not MC should be
> done separately
>
> Again not trying to regress original functionality.
Then it's better to switch to devm later. Only then it will
allow to optimize the error paths.
>>> - ret = led_classdev_register(dev, &led->cdev);
>>> if (ret) {
>>> dev_err(dev, "led register err: %d\n", ret);
>>> return ret;
>>> @@ -466,7 +526,6 @@ int lp55xx_register_leds(struct lp55xx_led *led,
>>> struct lp55xx_chip *chip)
>>> dev_err(&chip->cl->dev, "empty brightness configuration\n");
>>> return -EINVAL;
>>> }
>>> -
>>> for (i = 0; i < num_channels; i++) {
>>> /* do not initialize channels that are not connected */
>>> @@ -538,6 +597,39 @@ void lp55xx_unregister_sysfs(struct lp55xx_chip
>>> *chip)
>>> }
>>> EXPORT_SYMBOL_GPL(lp55xx_unregister_sysfs);
>>> +static int lp5xx_parse_channel_child(struct device_node *np,
>>> + struct lp55xx_led_config *cfg,
>>> + int chan_num)
>>> +{
>>> + struct device_node *child;
>>> + int num_colors = 0;
>>> + u32 color_id;
>>> + u32 led_number;
>>> + int ret;
>>> +
>>> + cfg[chan_num].default_trigger =
>>> + of_get_property(np, "linux,default-trigger", NULL);
>>> +
>>> + for_each_child_of_node(np, child) {
>>> + of_property_read_string(child, "chan-name",
>>> + &cfg[chan_num].name);
>>> + of_property_read_u8(child, "led-cur",
>>> + &cfg[chan_num].led_current);
>>> + of_property_read_u8(child, "max-cur",
>>> + &cfg[chan_num].max_current);
>>> + of_property_read_u32(child, "color", &color_id);
>>> + cfg[chan_num].channel_color[num_colors] = color_id;
>>> + cfg[chan_num].available_colors |= 1 << color_id;
>> set_bit(color_id, &cfg[chan_num].available_colors);
>
> Ack
>
>
>>
>>> + ret = of_property_read_u32(child, "reg", &led_number);
>>> + cfg[chan_num].grouped_channels[num_colors] = led_number;
>>> + num_colors++;
>>> + }
>>> +
>>> + cfg->num_colors = num_colors;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> struct lp55xx_platform_data *lp55xx_of_populate_pdata(struct device
>>> *dev,
>>> struct device_node *np)
>>> {
>>> @@ -545,6 +637,8 @@ struct lp55xx_platform_data
>>> *lp55xx_of_populate_pdata(struct device *dev,
>>> struct lp55xx_platform_data *pdata;
>>> struct lp55xx_led_config *cfg;
>>> int num_channels;
>>> + int num_chan_children;
>>> + u32 led_number;
>>> int i = 0;
>>> pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>>> @@ -565,13 +659,26 @@ struct lp55xx_platform_data
>>> *lp55xx_of_populate_pdata(struct device *dev,
>>> pdata->num_channels = num_channels;
>>> for_each_child_of_node(np, child) {
>>> - cfg[i].chan_nr = i;
>>> -
>>> - of_property_read_string(child, "chan-name", &cfg[i].name);
>>> - of_property_read_u8(child, "led-cur", &cfg[i].led_current);
>>> - of_property_read_u8(child, "max-cur", &cfg[i].max_current);
>>> - cfg[i].default_trigger =
>>> - of_get_property(child, "linux,default-trigger", NULL);
>>> + num_chan_children = of_get_child_count(child);
>>> + if (num_chan_children != 0)
>> You're already parsing color. If it is present and equals
>> LED_COLOR_ID_MULTI then we should expect children in the node.
>
> I don't see any parsing for color here but I suppose that I can add that
> now
I thought about that occurrence in lp5xx_parse_channel_child().
[...]
--
Best regards,
Jacek Anaszewski
Powered by blists - more mailing lists