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]

Date:	Tue, 8 Oct 2013 16:45:49 +0800
From:	Hongbo Zhang <hongbo.zhang@...escale.com>
To:	Eduardo Valentin <eduardo.valentin@...com>
CC:	<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 09/25/2013 10:15 PM, Eduardo Valentin wrote:
> 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.

We have thermal management plan in next year, currently I don't have 
proper board to test this.
I would like to do it when I have time and board, but I will track these 
thermal treads.
>
> Thanks for your interest in this work.
>
>>> +/* On cooling devices upper and lower limits */
>>> +#define THERMAL_NO_LIMIT        (-1UL)
>>> +
>>> +#endif
>>> [...]
>>
>>
>>
>



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