linux-kernel - Re: [PATCH 4/5] leds: flash: Add devm

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6ec62c8f-1522-b81a-1072-0cfa655f2b6f@gmail.com>
Date:   Wed, 2 Oct 2019 21:55:17 +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 4/5] leds: flash: Add devm_* functions to the flash class

Dan,

On 10/2/19 2:04 PM, Dan Murphy wrote:
> Jacek
> 
> On 10/1/19 4:06 PM, Jacek Anaszewski wrote:
>> Dan,
>>
>> Thank you for the patch. One funny omission caught my
>> eye here and in led-class.c when making visual comparison.
>> Please refer below.
>>
>> On 10/1/19 8:04 PM, Dan Murphy wrote:
>>> Add the missing device managed API for registration and
>>> unregistration for the LED flash class.
>>>
>>> Signed-off-by: Dan Murphy <dmurphy@...com>
>>> ---
>>>   drivers/leds/led-class-flash.c  | 50 +++++++++++++++++++++++++++++++++
>>>   include/linux/led-class-flash.h | 14 +++++++++
>>>   2 files changed, 64 insertions(+)
>>>
>>> diff --git a/drivers/leds/led-class-flash.c
>>> b/drivers/leds/led-class-flash.c
>>> index 60c3de5c6b9f..c2b4fd02a1bc 100644
>>> --- a/drivers/leds/led-class-flash.c
>>> +++ b/drivers/leds/led-class-flash.c
>>> @@ -327,6 +327,56 @@ void led_classdev_flash_unregister(struct
>>> led_classdev_flash *fled_cdev)
>>>   }
>>>   EXPORT_SYMBOL_GPL(led_classdev_flash_unregister);
>>>   +static void devm_led_classdev_flash_release(struct device *dev,
>>> void *res)
>>> +{
>>> +    led_classdev_flash_unregister(*(struct led_classdev_flash **)res);
>>> +}
>>> +
>>> +int devm_led_classdev_flash_register_ext(struct device *parent,
>>> +                     struct led_classdev_flash *fled_cdev,
>>> +                     struct led_init_data *init_data)
>>> +{
>>> +    struct led_classdev_flash **dr;
>>> +    int ret;
>>> +
>>> +    dr = devres_alloc(devm_led_classdev_flash_release, sizeof(*dr),
>>> +              GFP_KERNEL);
>>> +    if (!dr)
>>> +        return -ENOMEM;
>>> +
>>> +    ret = led_classdev_flash_register_ext(parent, fled_cdev,
>>> init_data);
>>> +    if (ret) {
>>> +        devres_free(dr);
>>> +        return ret;
>>> +    }
>>> +
>>> +    *dr = fled_cdev;
>>> +    devres_add(parent, dr);
>>> +
>>> +    return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(devm_led_classdev_flash_register_ext);
>>> +
>>> +static int devm_led_classdev_flash_match(struct device *dev,
>>> +                          void *res, void *data)
>>> +{
>>> +    struct fled_cdev **p = res;
>> We don't have struct fled_cdev. This name is used for variables
>> of struct led_clssdev_flash type in drivers.
>>
>> We don't get even compiler warning here because this is cast
>> from void pointer.
>>
>> Funny thing is that you seem to have followed similar flaw in
>> devm_led_classdev_match() where struct led_cdev has been
>> introduced.
>>
>> We need to fix both cases.
> 
> OK I will fix the leds-class in a separate patch in case it causes issues.

It doesn't cause issues now but is misleading.

-- 
Best regards,
Jacek Anaszewski