linux-kernel - Re: [RFC][PATCH V2 3/3] tegra: add pwm backlight device tree nodes

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: <4FFFB2DC.3040605@nvidia.com>
Date:	Fri, 13 Jul 2012 14:32:12 +0900
From:	Alex Courbot <acourbot@...dia.com>
To:	Simon Glass <sjg@...omium.org>
CC:	Thierry Reding <thierry.reding@...onic-design.de>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>
Subject: Re: [RFC][PATCH V2 3/3] tegra: add pwm backlight device tree nodes

On 07/12/2012 11:27 PM, Simon Glass wrote
>> I agree the type strings are a problem in the current form - if we could get
>> constants in the device tree, that would be much better. Your way of
>> representing the sequences is interesting though, if we can solve the type
>> issue (and also evaluate its cost in terms of memory footprint), it would be
>> interesting to consider it as well.
>
> At a guess:
>
>>>> +               power-on-sequence = "REGULATOR", "power", <1>,
>>>> +                                   "DELAY", <10>,
>>>> +                                   "PWM", "backlight", <1>,
>>>> +                                   "GPIO", "enable", <1>;
>
> About 106 bytes I think
>
>>>      step@0 { 16
>              type = "regulator"; 24
>>>         phandle = <&backlight_reg>; 16
>>>         enable = <1>; 16
>>>         post-delay = <10>; 16
>>>      }
>>>      step@1 { 16
>              type = "pwm"; 16
>>>         phandle = <&pwm 2 5000000>; 24
>>>      }
>>>      step@2 { 16
>              type = "gpio"; 20
>>>         phandle = <&gpio 28 0>; 24
>>>         enable = <1>; 16
>>>      }
>
> 220?

I compiled both versions to try it out. Your version was just 50 bytes 
larger than mine (I assumed that with yours, we would be able to remove 
the top-level pwm/regulator/gpio definitions that are referred by the 
sequence). The question here is do we want to have something more 
DT-ish, or are we trying to save every possible byte in the DT structure?

As Thierry also mentionned, we are trying to provide the same feature 
using the platform interface. I am not sure how we can elegantly support 
both ways through this.

>  From my understanding mixing strings and numbers in a property is
> frowned on though.

But doesn't it make sense in the current case? The power sequence is 
basically a program that is run by an interpreter. From this 
perspective, it makes more sense to me to have it as a binary field 
rather than a hierarchy of nodes and properties that will be harder to 
parse and will make error detection more complicated. I don't really see 
any practical benefit from turning the steps into sub-nodes, but then 
again I am not so familiar with the DT.

Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/