From: Dan Murphy <dmurphy@ti.com>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>, Pavel Machek <pavel@ucw.cz>,
devicetree <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux LED Subsystem <linux-leds@vger.kernel.org>
Subject: Re: [PATCH v6 2/2] leds: lm3601x: Introduce the lm3601x LED driver
Date: Wed, 16 May 2018 16:17:15 -0500 [thread overview]
Message-ID: <f155e9da-e41d-1201-a9f9-c321654be42e@ti.com> (raw)
In-Reply-To: <52380a68-9e33-f52a-134d-5d4a928b5383@ti.com>
Jacek and Andy
On 05/16/2018 04:13 PM, Dan Murphy wrote:
> Jacek and Andy
>
> On 05/16/2018 04:02 PM, Jacek Anaszewski wrote:
>> Hi Andy and Dan,
>>
>
> I will make all the changes then. I don't want to go through and ack each one.
>
Let me clarify. I will make all the change Jacek has guided on. There is still a
terminator comma vs no comma comment that needs disposition at the end of this file.
Dan
> Thanks for the guidance and the reviews.
>
> It will take a couple days to find all the comments and get this all fixed up.
>
> Dan
>
>> On 05/16/2018 12:24 AM, Andy Shevchenko wrote:
>>> On Wed, May 16, 2018 at 1:08 AM, Dan Murphy <dmurphy@ti.com> wrote:
>>>> On 05/15/2018 04:56 PM, Andy Shevchenko wrote:
>>>>> On Tue, May 15, 2018 at 6:43 PM, Dan Murphy <dmurphy@ti.com> wrote:
>>>
>>>>>> + depends on LEDS_CLASS && I2C && OF
>>>>>
>>>>> What is OF specific in this driver?
>>>>
>>>> as3645a_led_class_setup has a "of" dependency
>>>
>>> So what? Is it called from this driver or?
>>>
>>>
>>>>>> +static const struct lm3601x_max_timeouts strobe_timeouts[] = {
>>>>>> + { 40000, 0x00 },
>>>>>> + { 80000, 0x01 },
>>>>>> + { 120000, 0x02 },
>>>>>> + { 160000, 0x03 },
>>>>>> + { 200000, 0x04 },
>>>>>> + { 240000, 0x05 },
>>>>>> + { 280000, 0x06 },
>>>>>> + { 320000, 0x07 },
>>>>>> + { 360000, 0x08 },
>>>>>> + { 400000, 0x09 },
>>>>>> + { 600000, 0x0a },
>>>>>> + { 800000, 0x0b },
>>>>>> + { 1000000, 0x0c },
>>>>>> + { 1200000, 0x0d },
>>>>>> + { 1400000, 0x0e },
>>>>>> + { 1600000, 0x0f },
>>>>>
>>>>> Huh?!
>>>>
>>>> Please give comments that actually mean something other wise I will opt to ignore them.
>>>
>>> I did below.
>>>
>>>>> strobe_timeout = (x + 1) * 40 * MSECS_IN_SEC;
>>>>
>>>> Not sure what equation you are trying to point out here. But if you are trying to apply
>>>> a timeout step you cannot do this with this part. As pointed out in the DT doc the timeout
>>>> step is not linear.
>>>
>>> Yeah, I know people are more than often too lazy to think.
>>>
>>> if (x < 9)
>>> strobe_timeout = (x + 1) * 40 * MSECS_IN_SEC;
>>> else
>>> strobe_timeout = (400 + (x - 9) * 200) * MSECS_IN_SEC;
>>>
>>
>> I like the idea.
>>
>>>>>> + brightness_val = (brightness/2);
>>>>>
>>>>> Spaces.
>>>>
>>>> Not sure what this means checkpatch was clean
>>>
>>> Even besides missed whispaces it has redundant parens.
>>>
>>> checkpatch is not a silver bullet to get your code clean and nice.
>>>
>>>>> This is return led_...();
>>>>
>>>> That is a preference. It does not have to be that way.
>>
>> I missed that. Dan, please follow Andy's advise.
>>
>>>
>>> What do you mean? We do not appreciate +LOCs for no (or even nagative!) benefit.
>>>
>>>>>> + ret = of_property_read_string(led->led_node, "label", &name);
>>>>>
>>>>> device_property_...();
>>>>
>>>> It can be if the maintainer is requesting this.
>>>
>>> Jacek, if you need rationale behind this comment it's here: the driver
>>> has nothing DT specific and getting rid of OF centric programming
>>> allows to reuse the driver on non-DT platforms w/o touching a source
>>> code.
>>
>> It has an added value, so yes, let's use it as a standard approach
>> from now on.
>>
>>>> Is the trend to move to these functions?
>>>
>>> See above.
>>>
>>>> Most drivers use the "of" calls.
>>>
>>> So what?
>>>
>>>
>>>>>> + if (!ret)
>>>>>
>>>>> if (ret) sounds more natural. And better just to split
>>>>>
>>>>>> + snprintf(led->led_name, sizeof(led->led_name),
>>>>>> + "%s:%s", led->led_node->name, name);
>>>>>> + else
>>>>>> + snprintf(led->led_name, sizeof(led->led_name),
>>>>>> + "%s:torch", led->led_node->name);
>>>>>
>>>>> const char *tmp;
>>>>>
>>>>> ret = device_property_read_...(&tmp);
>>>>> if (ret)
>>>>> tmp = ...
>>>>> sprintf(...);
>>
>> We're no longer taking devicename section of a LED class device name
>> from DT, so it will look differently anyway.
>>
>>> No comments on this?
>>>
>>>>>> + led = devm_kzalloc(&client->dev,
>>>>>> + sizeof(struct lm3601x_led), GFP_KERNEL);
>>>>>
>>>>> sizeof(*led) and one line in the result
>>>
>>> And this?
>>
>> Ack.
>>
>>>
>>>>>> + { },
>>>>>
>>>>> Terminators better w/o comma.
>>>>
>>>> Looking at other drivers adding comma's on the sentinel is accepted. See the as3645a driver
>>>
>>> So what?
>>>
>>> Terminator at compile time even better.
>>>
>>>>>> + {},
>>>>>
>>>>> Ditto.
>>>>
>>>> See above
>>>
>>> See above.
>>>
>>
>
>
--
------------------
Dan Murphy
next prev parent reply other threads:[~2018-05-16 21:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-15 15:43 [PATCH v6 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver Dan Murphy
2018-05-15 15:43 ` [PATCH v6 2/2] leds: lm3601x: Introduce the lm3601x LED driver Dan Murphy
2018-05-15 21:24 ` Jacek Anaszewski
2018-05-15 21:50 ` Dan Murphy
2018-05-16 20:43 ` Jacek Anaszewski
2018-05-15 21:56 ` Andy Shevchenko
2018-05-15 22:08 ` Dan Murphy
2018-05-15 22:24 ` Andy Shevchenko
2018-05-15 22:27 ` Andy Shevchenko
2018-05-16 20:43 ` Dan Murphy
2018-05-16 22:11 ` Andy Shevchenko
2018-05-16 22:19 ` Andy Shevchenko
2018-05-16 21:02 ` Jacek Anaszewski
2018-05-16 21:13 ` Dan Murphy
2018-05-16 21:17 ` Dan Murphy [this message]
2018-05-16 21:27 ` Jacek Anaszewski
2018-05-17 14:34 ` Dan Murphy
2018-05-17 21:26 ` Jacek Anaszewski
2018-05-15 21:13 ` [PATCH v6 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver Jacek Anaszewski
2018-05-15 21:29 ` Dan Murphy
2018-05-16 20:10 ` Jacek Anaszewski
2018-05-16 20:14 ` Dan Murphy
2018-05-18 15:11 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f155e9da-e41d-1201-a9f9-c321654be42e@ti.com \
--to=dmurphy@ti.com \
--cc=andy.shevchenko@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).