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
| ||
|
Date: Thu, 17 Sep 2020 10:28:12 -0500 From: Dan Murphy <dmurphy@...com> To: Marek Behún <marek.behun@....cz>, <linux-leds@...r.kernel.org> CC: Pavel Machek <pavel@....cz>, Ondřej Jirman <megous@...ous.com>, <linux-kernel@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>, <devicetree@...r.kernel.org> Subject: Re: [PATCH leds v1 09/10] leds: lm36274: use struct led_init_data when registering Marek On 9/16/20 6:16 PM, Marek Behún wrote: > By using struct led_init_data when registering we do not need to parse > `label` DT property nor `linux,default-trigger` property. > > A small refactor was also done: > - with using devm_led_classdev_register_ext the driver remove method is > not needed > - since only one child node is allowed for this driver, use > device_get_next_child_node instead of device_for_each_child_node > > Previously if the `label` DT property was not present, the code composed > name for the LED in the form > "parent_name::" > For backwards compatibility we therefore set > init_data->default_label = ":"; > so that the LED will not get a different name if `label` property is not > present. You are going to re-factor this as well a lot of changes in a single patch is hard to review Dan
Powered by blists - more mailing lists