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] [thread-next>] [day] [month] [year] [list]
Message-ID: <5a738825-a8f9-f4ca-0a38-773fe145048f@gmail.com>
Date:   Wed, 24 Apr 2019 20:04:57 +0200
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Pavel Machek <pavel@....cz>
Cc:     linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, robh@...nel.org, dtor@...gle.com,
        linux@...ck-us.net, Baolin Wang <baolin.wang@...aro.org>,
        Dan Murphy <dmurphy@...com>, Daniel Mack <daniel@...que.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Oleh Kravchenko <oleg@....org.ua>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Simon Shields <simon@...eageos.org>
Subject: Re: [PATCH v4 02/26] leds: class: Improve LED and LED flash class
 registration API

Hi Pavel,

Thanks for the review.

On 4/24/19 3:46 PM, Pavel Machek wrote:
> Hi!
> 
>> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@...il.com>
>> Cc: Baolin Wang <baolin.wang@...aro.org>
> 
> Acked-by: Pavel Machek <pavel@....cz>
> 
>> +/**
>> + * led_classdev_register_ext - register a new object of LED class with
>> + *			       init data
>> + * @parent: LED controller device this LED is driven by
>> + * @led_cdev: the led_classdev structure for this device
>> + * @init_data: the LED class device initialization data
>> + *
>> + * Returns: 0 on success or negative error value on failure
>> + */
>> +extern int led_classdev_register_ext(struct device *parent,
>> +				     struct led_classdev *led_cdev,
>> +				     struct led_init_data *init_data);
>> +#define led_classdev_register(parent, led_cdev)			\
>> +	led_classdev_register_ext(parent, led_cdev, NULL)
>> +extern int devm_led_classdev_register_ext(struct device *parent,
>> +					  struct led_classdev *led_cdev,
>> +					  struct led_init_data *init_data);
>> +#define devm_led_classdev_register(parent, led_cdev)		\
>> +	devm_led_classdev_register_ext(parent, led_cdev, NULL)
> 
> Static inline (instead of macro) might be preffered. More type safety
> and less confusing behaviour in case of errors...

This is kind of alias. You have type control in the function being
mapped. With inline we'd have to nest the function calls, i.e.
it will worsen performance by this one additional call level.

-- 
Best regards,
Jacek Anaszewski

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ