mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®