devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Jacek Anaszewski <j.anaszewski@samsung.com>,
	linux-leds@vger.kernel.org, Bryan Wu <cooloney@gmail.com>,
	Richard Purdie <rpurdie@rpsys.net>, Pavel Machek <pavel@ucw.cz>,
	devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <Mark.Rutland@arm.com>
Subject: Re: [PATCH v5] DT: leds: Improve description of flash LEDs related properties
Date: Thu, 09 Apr 2015 12:03:25 +0200	[thread overview]
Message-ID: <55264E6D.40801@samsung.com> (raw)
In-Reply-To: <55263247.5070009@linux.intel.com>

On 09/04/15 10:03, Sakari Ailus wrote:
> Jacek Anaszewski wrote:
>> On 04/08/2015 05:15 PM, Sylwester Nawrocki wrote:
>>> On 08/04/15 16:31, Jacek Anaszewski wrote:
>>>> Properties defining maximum values for LED currents and timeout should
>>>> be mandatory to avoid the risk of hardware damage. This patch fixes
>>>> the issue.

>>>> --- a/Documentation/devicetree/bindings/leds/common.txt
>>>> +++ b/Documentation/devicetree/bindings/leds/common.txt
>>>> @@ -10,6 +10,17 @@ can influence the way of the LED device
>>>> initialization, the LED components
>>>>   have to be tightly coupled with the LED device binding. They are
>>>> represented
>>>>   by child nodes of the parent LED device binding.
>>>>
>>>> +Required properties for child nodes:
>>>
>>> These properties are mandatory only for LEDs with Flash/Torch
>>> capabilities, aren't they?
>>
>> flash-max-microamp and flash-timeout-us properties description mention
>> that they refer to flash LEDs. Perhaps this should be made indeed more
>> explicit.
> 
> Sounds good to me, after all these shouldn't be defined for devices they
> don't make sense for. Alternatively, you could add another section for
> "required properties for flash LEDs".

Sounds good to me.

>>> Requiring those properties for all led nodes would make all
>>> current dtses not compliant with the DT binding specification AFAICT.
> 
> Some drivers also define these explicitly as optional, the behaviour for
> those obviously can't be changed.  This should apply to new drivers
> only, and I think documenting the matter in this file would be the best
> way to do that.

Unfortunately this file is not a proper place for information regarding
Linux drivers.
I can't see any drivers in -next using those DT properties. Could you
point to any examples?
Perhaps we should stay with the below properties specified as optional
in general and add a note they can be mandatory for some LEDs (controllers)?

>> I was also worrying about making led-max-microamp required, but others
>> didn't share my objections. I think that we have to reexamine this.
>>
>> Please refer to the discussion under [PATCH v4]. The role of this
>> led-max-microamp property would be preventing hardware damage.
>>
>>
>>> How about:
>>>
>>> "Required properties for child nodes for LEDs with Flash/Torch
>>> capabilities:" ?
>>>
>>>> +- led-max-microamp : Maximum LED supply current in microamperes
>>>> +                     (torch LED for flash devices). Controllers that
> 
> Do you think we can just rename max-microamp as led-max-microamp? It's
> been there since v3.19. Or is it because no driver has been using it?

I'd say it could be renamed if there is no users in mainline. But the DT
maintainers could disagree here (adding Rob, Mark at Cc).

>>>> have no
>>>> +                     configurable current can omit this property.
>>>> +- flash-max-microamp : Maximum flash LED supply current in
>>>> microamperes.
>>>> +- flash-timeout-us : Timeout in microseconds after which the flash
>>>> +                     LED is turned off.
>>>> +
>>>
>>>> +Above properties determine a LED driver IC settings required for safe
>>>> +operation. They should be also used as the initial settings for the IC.
>>>
>>> Shouldn't "Controllers that have no configurable current can omit this
>>> property" refer to both led-max-microamp and flash-max-microamp?
>>>
>>> I would drop the "Above...for the IC." paragraph and instead add
>>> something like:
>>>
>>> "For controllers that have no configurable current the led-max-microamp,
>>> flash-max-microamp properties respectively can be omitted. For
>>> controllers that
>>> have no configurable timeout the flash-timeout-us property can be
>>> omitted."
>>
>> Are we going to avoid mentioning about their role in preventing
>> hardware damage (former "for safe operation" sequence)?
> 
> That'd make it understandable why the properties are mandatory. Sounds
> good to me.

-- 
Regards,
Sylwester

  reply	other threads:[~2015-04-09 10:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-08 14:31 [PATCH v5] DT: leds: Improve description of flash LEDs related properties Jacek Anaszewski
2015-04-08 15:15 ` Sylwester Nawrocki
2015-04-09  7:23   ` Jacek Anaszewski
2015-04-09  8:03     ` Sakari Ailus
2015-04-09 10:03       ` Sylwester Nawrocki [this message]
2015-04-09 14:39         ` Jacek Anaszewski
2015-04-09 23:25           ` Sakari Ailus
2015-04-09  9:45     ` Sylwester Nawrocki

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=55264E6D.40801@samsung.com \
    --to=s.nawrocki@samsung.com \
    --cc=Mark.Rutland@arm.com \
    --cc=cooloney@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=j.anaszewski@samsung.com \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=rpurdie@rpsys.net \
    --cc=sakari.ailus@linux.intel.com \
    /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).