linux-kernel - Re: [PATCHv6 02/16] drivers: 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: <5242F011.4090607@ti.com>
Date:	Wed, 25 Sep 2013 10:15:45 -0400
From:	Eduardo Valentin <eduardo.valentin@...com>
To:	Hongbo Zhang <hongbo.zhang@...escale.com>
CC:	Eduardo Valentin <eduardo.valentin@...com>,
	<swarren@...dotorg.org>, <pawel.moll@....com>,
	<mark.rutland@....com>, <ian.campbell@...rix.com>,
	<rob.herring@...xeda.com>, <linux@...ck-us.net>,
	<rui.zhang@...el.com>, <wni@...dia.com>, <joe@...ches.com>,
	<grant.likely@...aro.org>, <durgadoss.r@...el.com>,
	<lm-sensors@...sensors.org>, <linux-kernel@...r.kernel.org>,
	<linux-pm@...r.kernel.org>
Subject: Re: [PATCHv6 02/16] drivers: thermal: introduce device tree parser

On 25-09-2013 03:13, Hongbo Zhang wrote:
> On 09/19/2013 05:35 AM, Eduardo Valentin wrote:
>>   [...]
>> +
>> +/***   sensor API   ***/
>> +
> 
> You are introducing new concept here, the original framework and drivers
> cannot use this, right? any further plan to update original framework
> for this new feature?
> 

Well, not new as such. Just a specific way to register sensors to
thermal framework. What is really new is the fact that we really need to
have sensors decoupled from thermal zone devices, and today we have
these concepts pretty merged together.

To answer your question, for now I am more concerned with the bindings
definition. Once that is at least agreed, then we can follow up with the
migration of existing drivers. For now, there are two examples in this
series, first one is using one existing thermal driver, which is the TI
SoC thermal driver, and the second one is the hwmon drivers, which are
existing sensor drivers, but are not thermal drivers.

The plan forward, once this series is accepted is to migrate existing
drivers, yes, so that they can use device tree uniformly. Of course,
this needs help from driver authors.

My proposal will be to follow up this series with a two fold migration.
First step to change the existing thermal drivers to have both, the
current support and the device tree support. And second step, for those
who wish to, we could remove the old code containing thermal data and
have only dt support. Of course, this requires drivers authors input.

>> +static struct thermal_zone_device *
>> +thermal_zone_of_add_sensor(struct device_node *zone,
>> +               struct device_node *sensor, void *data,
>> +               int (*get_temp)(void *, long *),
>> +               int (*get_trend)(void *, long *))
>> +{
>> +    struct thermal_zone_device *tzd;
>> +    struct __thermal_zone *tz;
>> +
>> +    tzd = thermal_zone_get_zone_by_name(zone->name);
>> +    if (IS_ERR(tzd))
>> +        return ERR_PTR(-EPROBE_DEFER);
>> +
>> [...]
>> +
>> +/*
>> + * Here are the thermal trip types. This must
>> + * match with enum thermal_trip_type at
>> + * include/linux/thermal.h
>> + */
>> +#define THERMAL_TRIP_ACTIVE        0
>> +#define THERMAL_TRIP_PASSIVE        1
>> +#define THERMAL_TRIP_HOT        2
>> +#define THERMAL_TRIP_CRITICAL        3
>> +
> 
> These macros seem duplicated with enum thermal_trip_type in thermal.h,
> do you have further plan to merge them?
> Or by using string "active",  "passive" etc in the dts, then you can
> reuse the original enum definition.

I am changing this so that in DT we have string constants, and we keep a
map from string to enum, just like we have for phy-mode, as suggested by
Mark.

You can have a taste of it here:
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux.git/commit/?h=thermal_work/thermal_core/dt_parser_rfc_v4&id=73f16c27fc763495188fba7d6e17b9c986efc6ac

I will be reposting this version once we are done with this thread
discussion and I am finished with my current test.

If you have the time, I would appreciate if you could try the series on
your board, as I am don't have access to your hardware. It would be
really nice to see how this work is behaving in other environments then
the one I have.

Thanks for your interest in this work.

> 
>> +/* On cooling devices upper and lower limits */
>> +#define THERMAL_NO_LIMIT        (-1UL)
>> +
>> +#endif
>> [...]
> 
> 
> 
> 

-- 
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)