linux-kernel - Re: [RFC PATCH 2/4] thermal: introduce device tree parser

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: <51E40783.3070402@ti.com>
Date:	Mon, 15 Jul 2013 10:30:27 -0400
From:	Eduardo Valentin <eduardo.valentin@...com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	Wei Ni <wni@...dia.com>,
	Eduardo Valentin <eduardo.valentin@...com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"durgadoss.r@...el.com" <durgadoss.r@...el.com>,
	"amit.daniel@...sung.com" <amit.daniel@...sung.com>,
	"rui.zhang@...el.com" <rui.zhang@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 2/4] thermal: introduce device tree parser

On 10-07-2013 11:16, Stephen Warren wrote:
> On 07/10/2013 12:48 AM, Wei Ni wrote:
>> On 07/09/2013 10:00 PM, Eduardo Valentin wrote:
>>> In order to be able to build thermal policies
>>> based on generic sensors, like I2C device, that
>>> can be places in different points on different boards,
>>> there is a need to have a way to feed board dependent
>>> data into the thermal framework.
>>>
>>> This patch introduces a thermal data parser for device
>>> tree. The parsed data is used to build thermal zones
>>> and thermal binding parameters. The output data
>>> can then be used to deploy thermal policies.
>>>
>>> This patch adds also documentation regarding this
>>> API and how to define define tree nodes to use
>>> this infrastructure.
>>
>> It looks good, with this infrastructure, we can add generic sensor
>> driver into the thermal fw easily.
>>
>>
>>> +
>>> +Below is an example:
>>> +thermal_zone {
>>> +            type = "CPU";
>>> +            mask = <0x03>; /* trips writability */
>>> +            passive_delay = <250>; /* milliseconds */
>>> +            polling_delay = <1000>; /* milliseconds */
>>> +            governor = "step_wise";
>>> +            trips {
>>> +                    alert@...000{
>>> +                            temperature = <100000>; /* milliCelsius */
>>> +                            hysteresis = <0>; /* milliCelsius */
>>> +                            type = <1>;
>>
>> how about to use the trip type name directly, such as named as
>> "passive-trip;", I think it's more readable. for example:
>> trip0 {
>> ....
>> passive-trip;
>> }
>> trip1 {
>> ....
>> active-trip;
>> }
> 
> You can always use the C pre-processor in DT now to define named constants:
> 
> include/dt-bindings/..../....h
> 
> 	#define THERMAL_PASSIVE_TRIP 0
> 	#define THERMAL_ACTIVE_TRIP 1
> 
> *.dts:
> 
> 	type = <THERMAL_PASSIVE_TRIP>;
> 
> Having a single 'property = value;' rather than n different Boolean
> property names seems better, irrespective of whether value is an integer
> or string; parsing and error-checking will be simpler.

agreed here. I will amend with the above suggestions. makes the dt file
much more readable. thanks Stephen and Wei.

> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


Download attachment "signature.asc" of type "application/pgp-signature" (296 bytes)