linux-kernel - Re: [PATCH v2 1/2] dt: bindings: lm3697: Add bindings for lm3697 driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c028fb73-8df5-9402-d96e-c907199356ed@ti.com>
Date:   Thu, 9 Aug 2018 08:30:28 -0500
From:   Dan Murphy <dmurphy@...com>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>
CC:     <robh+dt@...nel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-leds@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] dt: bindings: lm3697: Add bindings for lm3697
 driver

Jacek and Pavel

On 08/09/2018 07:09 AM, Jacek Anaszewski wrote:
> Dan,
> 
> On 08/08/2018 11:45 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 08/08/2018 04:09 PM, Jacek Anaszewski wrote:
>>> Hi Dan,
>>>
>>> On 08/08/2018 11:04 PM, Dan Murphy wrote:
>>>> On 08/08/2018 04:02 PM, Pavel Machek wrote:
>>>>> Hi!
>>>>>
>>>>>>>> +	- #size-cells : 0
>>>>>>>> +	- control-bank-cfg - : Indicates which sink is connected to which control bank
>>>>>>>> +		0 - All HVLED outputs are controlled by bank A
>>>>>>>> +		1 - HVLED1 is controlled bank B, HVLED2/3 are controlled by bank A
>>>>>>>> +		2 - HVLED2 is controlled bank B, HVLED1/3 are controlled by bank A
>>>>>>>> +		3 - HVLED1/2 are controlled by bank B, HVLED3 is controlled by bank A
>>>>>>>> +		4 - HVLED3 is controlled by bank B, HVLED1/2 are controlled by bank A
>>>>>>>> +		5 - HVLED1/3 is controlled by bank B, HVLED2 is controlled by bank A
>>>>>>>> +		6 - (default) HVLED1 is controlled by bank A, HVLED2/3 are controlled by bank B
>>>>>>>> +		7 - All HVLED outputs are controlled by bank B
>>>>>>>
>>>>>>> This is quite long way to describe a bitmask, no? Could we make
>>>>>>> it so that control-bank-cfg is not needed?
>>>>>>
>>>>>> The problem we have here is there is a potential to control
>>>>>> 3 different LED string but only 2 sinks.  So control bank A can control 2 LED strings and control
>>>>>> bank b can control 1 LED string.  
>>>>>>
>>>>>
>>>>> Can we forget about the LED strings, and just expose the sinks as
>>>>> Linux LED devices?
>>>>
>>>> 2 sinks 3 LED strings.  How do you know which LED string is which and what bank it belongs
>>>> to when setting the brightness.  Each Bank has a separate register for brightness control.
>>>
>>> Just a blind shot, without going into details - could you please check
>>> if led-sources property documented in the common LED bindings couldn't
>>> help here?
>>>
>>
>> I could change the name to led-sources.  But this part does not really follow the 1 output to a
>> 1 LED string topology.
> 
> led-sources was designed for describing the topology where one LED can
> be connected to more then one output, see bindings of
> max77693-led (in Documentation/devicetree/bindings/mfd/max77693.txt).
> 
> Here the topology is a bit different - more than one LED (string) can be
> connected to a single bank, but this is accomplished inside the chip.
> Logically LEDs configured that way can be treated as a single LED
> (string) connected to two outputs, and what follows they should be
> described by a single DT child node.
> 
> led-sources will fit very well for this purpose. You could do
> the following mapping:
> 
> 0 - HVLED1
> 1 - HVLED2
> 2 - HVLED3
> 
> Then, in the child DT nodes you would use these identifiers to describe
> the topology:
> 
> Following node would describe strings connected to the outputs
> HVLED1 and HVLED2 controlled by bank A.
> 
> led@0 {
> 	reg = <0>;
> 	led-sources = <0>. <1>;
> 	label = "white:first_backlight_cluster";
> 	linux,default-trigger = "backlight";
> };
> 
> 
> IOW I agree with Pavel, but I propose to use already documented common
> DT LED property.
> 

I agree to use the led-sources but I still believe this approach may be confusing to other sw devs
and will lead to configuration issues by users.

This implementation requires the sw dev to know which strings are controlled by which bank.
And this method may produce a misconfiguration like something below where HVLED2 is declared in
both bank A and bank B

led@0 {
	reg = <0>;
	led-sources = <0>. <1>;
	label = "white:first_backlight_cluster";
	linux,default-trigger = "backlight";
};

led@1 {
	reg = <1>;
	led-sources = <1>. <2>;
	label = "white:keypad_cluster";
	linux,default-trigger = "backlight";
};

The driver will need to be intelligent and declare a miss configuration on the above.
Not saying this cannot be done but I am not sure why we want to add all of these extra LoC and intelligence
in the kernel driver.
The driver cannot make assumptions on the intention.  And the device tree documentation will need to
pretty much need a lengthy explanation on how to configure the child nodes.

The implementation I suggested removes that ambiguity.  It is a simple integer that is written to the device
as part of the device configuration, which the config is a setting for the device.

The child nodes denote which bank the exposed LED node will control.  Removing any need
for the sw developers new or old to know the specific device configurations.


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