mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dan Murphy <dmurphy@ti.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: <robh+dt@kernel.org>, <mark.rutland@arm.com>, <rpurdie@rpsys.net>,
	<jacek.anaszewski@gmail.com>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-leds@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] leds: lm3692x: Introduce LM3692x dual string driver
Date: Wed, 15 Nov 2017 15:25:42 -0600	[thread overview]
Message-ID: <abe5f2cc-9216-6f0b-8063-8a0079557ecf@ti.com> (raw)
In-Reply-To: <20171115211236.GD6183@amd>

Pavel

On 11/15/2017 03:12 PM, Pavel Machek wrote:
> Hi!
> 
>> Introducing the LM3692x Dual-String white LED driver.
>>
>> Data sheet is located
> 
> "located at"? (Twice.)

Actually it is 3x since I call it out in the dt binding as well.

So what to eliminate?

> 
>> http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> 
>> +config LEDS_LM3692X
>> +	tristate "LED support for LM3692x Chips"
>> +	depends on LEDS_CLASS && I2C
>> +	select REGMAP_I2C
>> +	help
>> +	  This option enables support for the TI LM3692x family
>> +	  of LED drivers.
> 
> "If unsure ..., module will be named..."
> 
> Might want to say this is for backlight LEDs here.

AcK

> 
>> +static int lm3692x_fault_check(struct lm3692x_led *led)
>> +{
>> +	int ret, fault;
>> +	unsigned int read_buf;
>> +
>> +	ret = regmap_read(led->regmap, LM3692X_FAULT_FLAGS, &read_buf);
>> +	if (ret)
>> +		return ret;
>> +
>> +	fault = read_buf;
>> +
>> +	if (fault)
>> +		dev_err(&led->client->dev, "Detected a fault 0x%X\n",
>> +			fault);
>> +
>> +	return ret;
>> +}
> 
> Get rid of "fault" variable?
> 
> Does fault need to be propagated to the caller?

I should probably set ret to fail if I see a fault or as you suggest propagate the fault

> 
> 
>> +static int lm3692x_init(struct lm3692x_led *led)
>> +{
>> +	int ret;
>> +
>> +	if (led->regulator) {
>> +		ret = regulator_enable(led->regulator);
>> +		if (ret)
>> +			dev_err(&led->client->dev,
>> +				"Failed to enable regulator\n");
>> +			goto out;
>> +	}
>> +
>> +	if (led->enable_gpio)
>> +		gpiod_direction_output(led->enable_gpio, 1);
>> +
>> +	ret = lm3692x_fault_check(led);
>> +	if (ret) {
>> +		dev_err(&led->client->dev, "Cannot read/clear faults\n");
>> +		goto out;
>> +	}
>> +
>> +	ret = regmap_write(led->regmap, LM3692X_BRT_CTRL, 0x00);
>> +	if (ret) {
>> +		dev_err(&led->client->dev, "Fail writing BRT CTRL\n");
>> +		goto out;
>> +	}
> 
> How often are those fails reached? Maybe regmap wrapper that would
> print "reading/writing register XY failed" would be enough?

Or maybe in the out label I can just dev_err once saying initializing the device failed.
These are really only called at probe time.  Its the only time init is called.

Dan

> 
> Otherwise looks good,
> 
> Acked-by: Pavel Machek <pavel@ucw.cz>
> 									Pavel
> 


-- 
------------------
Dan Murphy

  reply	other threads:[~2017-11-15 21:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-15 19:42 [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver Dan Murphy
2017-11-15 19:42 ` [PATCH v3 2/2] leds: lm3692x: Introduce LM3692x dual string driver Dan Murphy
2017-11-15 21:12   ` Pavel Machek
2017-11-15 21:25     ` Dan Murphy [this message]
2017-11-18 14:19   ` Jacek Anaszewski
2017-11-28 12:53     ` Dan Murphy
2017-11-15 20:15 ` [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver Jacek Anaszewski
2017-11-15 20:31   ` Dan Murphy
2017-11-15 22:23     ` Pavel Machek
2017-11-16 20:14       ` Jacek Anaszewski
2017-11-16 21:42         ` Dan Murphy
2017-11-17  2:19           ` Jingoo Han
2017-11-17 11:20           ` Pavel Machek
2017-11-17 16:30             ` Jingoo Han
2017-11-17 18:02               ` Dan Murphy
2017-11-17 23:58                 ` Pavel Machek
2017-11-28 17:27                   ` Dan Murphy
2017-11-16 15:41 ` Rob Herring
2017-11-16 15:45   ` Dan Murphy
2017-11-16 15:58     ` Rob Herring
2017-11-16 20:11     ` dts: fun with chip names " Pavel Machek
2017-11-16 20:36       ` Rob Herring
2017-11-16 21:40         ` Dan Murphy
2017-11-18 14:19 ` Jacek Anaszewski

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=abe5f2cc-9216-6f0b-8063-8a0079557ecf@ti.com \
    --to=dmurphy@ti.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 \
    --cc=rpurdie@rpsys.net \
    /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®