From: Dan Murphy <dmurphy@ti.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Jacek Anaszewski <jacek.anaszewski@gmail.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: Tue, 15 May 2018 17:08:22 -0500 [thread overview]
Message-ID: <08dda10d-f865-9cf2-b9a5-c79cbab5da98@ti.com> (raw)
In-Reply-To: <CAHp75VegjkiiD1qTGpi9rr6cg=72t9kSwDrG=sUpUWFVO58M4A@mail.gmail.com>
Andy
Thanks for the review
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:
>> Introduce the family of LED devices that can
>> drive a torch, strobe or IR LED.
>>
>> The LED driver can be configured with a strobe
>> timer to execute a strobe flash. The IR LED
>> brightness is controlled via the torch brightness
>> register.
>>
>> The data sheet for each the LM36010 and LM36011
>> LED drivers can be found here:
>> http://www.ti.com/product/LM36010
>> http://www.ti.com/product/LM36011
>
>> + depends on LEDS_CLASS && I2C && OF
>
> What is OF specific in this driver?
as3645a_led_class_setup has a "of" dependency
>
>
>> +#define LM3601X_STRB_LVL_TRIG ~BIT(3)
>
>> +#define LM36010_BOOST_LIMIT_19 ~BIT(5)
>
>> +#define LM36010_BOOST_FREQ_2MHZ ~BIT(6)
>
>> +#define LM36010_BOOST_MODE_NORM ~BIT(7)
>
> These looks rather strange. Shouldn't be just 0:s?
I don't actually use these so I can just remove them
>
>> +struct lm3601x_led {
>> + struct mutex lock;
>> + struct regmap *regmap;
>> + struct i2c_client *client;
>
>> + struct device_node *led_node;
>
> Why do you need this?
I don't but I can store it locally. I was using the nodes in the register
functions in previous versions.
>
>> +};
>
>> +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.
>
> 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.
>
>> +};
>
>> + struct lm3601x_led *led = fled_cdev_to_led(fled_cdev);
>> + int ret;
>> + int current_timeout;
>> + int reg_count;
>> + int i;
>> + int timeout_reg_val = 0;
>
> Better to put lines here in reversed xmas tree order (longest first).
I can do that, again this is a preference.
>
>> + reg_count = ARRAY_SIZE(strobe_timeouts);
>> + for (i = 0; i < reg_count; i++) {
>> + if (led->strobe_timeout > strobe_timeouts[i].timeout)
>> + continue;
>
> binary search?
>
> Check lib/bsearch.c (IIRC).
>
> But! See above the formula.
>
>> + brightness_val = (brightness/2);
>
> Spaces.
Not sure what this means checkpatch was clean
>
>> +static int lm3601x_register_leds(struct lm3601x_led *led)
>> +{
>
>
>> + int err = -ENODEV;
>
> Useless assignment.
This is an artifact from prior versions I can remove it
>
>> + err = led_classdev_flash_register(&led->client->dev,
>> + fled_cdev);
>> +
>> + return err;
>
> This is return led_...();
That is a preference. It does not have to be that way.
>
>> +}
>
>> + ret = of_property_read_string(led->led_node, "label", &name);
>
> device_property_...();
It can be if the maintainer is requesting this.
Is the trend to move to these functions?
Most drivers use the "of" calls.
>
>> + 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(...);
>
>> + led = devm_kzalloc(&client->dev,
>> + sizeof(struct lm3601x_led), GFP_KERNEL);
>
> sizeof(*led) and one line in the result
>
>> +static const struct i2c_device_id lm3601x_id[] = {
>> + { "LM36010", CHIP_LM36010 },
>> + { "LM36011", CHIP_LM36011 },
>> + { },
>
> Terminators better w/o comma.
Looking at other drivers adding comma's on the sentinel is accepted. See the as3645a driver
>
>> +};
>> +MODULE_DEVICE_TABLE(i2c, lm3601x_id);
>> +
>> +static const struct of_device_id of_lm3601x_leds_match[] = {
>> + { .compatible = "ti,lm36010", },
>> + { .compatible = "ti,lm36011", },
>> + {},
>
> Ditto.
See above
>
>> +};
>> +MODULE_DEVICE_TABLE(of, of_lm3601x_leds_match);
>
>
>
>
--
------------------
Dan Murphy
next prev parent reply other threads:[~2018-05-15 22:08 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 [this message]
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
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=08dda10d-f865-9cf2-b9a5-c79cbab5da98@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
all inboxes | Powered by JetHome®