[PATCH v2] thermal: consistently use int for temperatures

Guenter Roeck linux at roeck-us.net
Fri Jul 24 15:49:41 PDT 2015


On 07/24/2015 03:11 PM, Pavel Machek wrote:
> On Fri 2015-07-24 06:59:26, Guenter Roeck wrote:
>> On 07/23/2015 11:29 PM, Sascha Hauer wrote:
>>> On Thu, Jul 23, 2015 at 02:07:59PM +0200, Pavel Machek wrote:
>>>> On Tue 2015-07-21 09:21:32, Sascha Hauer wrote:
>>>>> The thermal code uses int, long and unsigned long for temperatures
>>>>> in different places.
>>>>>
>>>>> Using an unsigned type limits the thermal framework to positive
>>>>> temperatures without need. Also several drivers currently will report
>>>>> temperatures near UINT_MAX for temperatures below 0°C. This will probably
>>>>> immediately shut the machine down due to overtemperature if started below
>>>>> 0°C.
>>>>>
>>>>> 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
>>>>> is above the melting point of all known materials.
>>>>
>>>> Can we do something like
>>>>
>>>> typedef millicelsius_t int;
>>>>
>>>> ...to document the units?
>>>
>>> I am not very fond of typedefs and I am not sure this adds any value. I
>>> could change it when more people ask for it, but I just sent the new
>>> version without this.
>>>
>>
>> I thought we are supposed to not introduce new typedefs anyway.
>
> You are not supposed to typedef struct, but typedef for millicelsius_t
> would be ok. And it is your only chance if you want people to pay
> attention. If you make it int, someone will pass it to long or
> something else..

Seems to me that would be just lazyness. The same person might use 'long'
even if millicelsius_t is defined. A typedef doesn't preclude people
from ignoring it.

Guenter




More information about the linux-arm-kernel mailing list