Re: [PATCH v3 3/3] hwmon: Add Baikal-T1 PVT sensor driver

[Guenter Roeck]

On 5/27/20 10:05 AM, Serge Semin wrote:
> On Wed, May 27, 2020 at 09:58:00AM -0700, Guenter Roeck wrote:
>> On 5/27/20 9:52 AM, Serge Semin wrote:
>>> On Wed, May 27, 2020 at 09:25:49AM -0700, Guenter Roeck wrote:
>>>> On Tue, May 26, 2020 at 04:38:23PM +0300, Serge Semin wrote:
>>>
>>> [nip]
>>>
>>>>> +
>>>>> +=============================== ======= =======================================
>>>>> +Name				Perm	Description
>>>>> +=============================== ======= =======================================
>>>>> +update_interval			RW	Measurements update interval per
>>>>> +					sensor.
>>>>> +temp1_type			RO	Sensor type (always 1 as CPU embedded
>>>>> +					diode).
>>>>> +temp1_label			RO	CPU Core Temperature sensor.
>>>>> +temp1_input			RO	Measured temperature in millidegree
>>>>> +					Celsius.
>>>>> +temp1_min			RW	Low limit for temp input.
>>>>> +temp1_max			RW	High limit for temp input.
>>>>> +temp1_min_alarm			RO	Temperature input alarm. Returns 1 if
>>>>> +					temperature input went below min limit,
>>>>> +					0 otherwise.
>>>>> +temp1_max_alarm			RO	Temperature input alarm. Returns 1 if
>>>>> +					temperature input went above max limit,
>>>>> +					0 otherwise.
>>>>> +temp1_trim			RW	Temperature sensor trimming factor in
>>>>> +					millidegree Celsius. It can be used to
>>>>> +					manually adjust the temperature
>>>>> +					measurements within 7.130 degrees
>>>>> +					Celsius.
>>>>
>>>> vs. standard ABI:
>>>>
>>>> temp[1-*]_offset`
>>>>                 Temperature offset which is added to the temperature reading
>>>>                 by the chip.
>>>>
>>>>                 Unit: millidegree Celsius
>>>>
>>>> If you really think this is necessary, why not use the standard ABI ?
>>>
>>> That would have made much more sense.) I'll replace the handwritten temp1_trim
>>> with the standard temp1_offset attribute in v4 shortly today. Thanks for pointing
>>> this out.
>>>
>>
>> Sorry for not realizing this earlier. The added explanation
>> made all the difference.
> 
> No worries. I'll fix it in v4. What about the clk_get_rate() part of the code?
> You had a comment regarding it in v2. I responded with justification that we can
> leave it as is. If you still disagree, then I create the clock rate caching in the
> private data at the probe() stage.
> 
Reason asking for it is that clk_get_rate() is unnecessarily costly if the rate
doesn't change. But it isn't worth bike shedding about it.

Guenter

> -Sergey
> 
>>
>> Guenter