[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VcFR4zUOhRjNLN1nMirirVaK-WjYa5Kwa9dL__-bjnLuA@mail.gmail.com>
Date: Mon, 14 May 2018 22:49:51 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Dan Murphy <dmurphy@...com>
Cc: Jacek Anaszewski <jacek.anaszewski@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Pavel Machek <pavel@....cz>, "Andrew F. Davis" <afd@...com>,
devicetree <devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux LED Subsystem <linux-leds@...r.kernel.org>
Subject: Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver
On Mon, May 14, 2018 at 10:40 PM, Dan Murphy <dmurphy@...com> wrote:
> On 05/11/2018 06:56 AM, Dan Murphy wrote:
>>>> + ret = of_property_read_string(led->strobe_node, "label", &name);
>>>> + ret = of_property_read_u32(led->strobe_node,
>>>> + ret = of_property_read_u32(led->strobe_node,
>>> Common LED bindings state that flash-max-microamp and
>>> flash-max-timeout-us properties are mandatory.
>>
>> OK.
>
> OK I looked at the max776973 driver and well if the flash-max-microamp and
> flash-max-timeout-us nodes are missing it sets a default value for each if the
> node is not present.
>
> So should we remove this code from the Max77693 driver too and fail probe as being asked
> in this driver?
I would also add that using device_property_*() API is much better
then using OF specific one. It will help IoT / DIY entusiasts use them
on non-DT platforms.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists