Thread (11 messages) 11 messages, 3 authors, 2020-05-27

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

From: Guenter Roeck <linux@roeck-us.net>
Date: 2020-05-27 18:48:36
Also in: linux-doc, linux-hwmon, linux-mips, lkml

On 5/27/20 10:05 AM, Serge Semin wrote:
On Wed, May 27, 2020 at 09:58:00AM -0700, Guenter Roeck wrote:
quoted
On 5/27/20 9:52 AM, Serge Semin wrote:
quoted
On Wed, May 27, 2020 at 09:25:49AM -0700, Guenter Roeck wrote:
quoted
On Tue, May 26, 2020 at 04:38:23PM +0300, Serge Semin wrote:
[nip]
quoted
quoted
+
+=============================== ======= =======================================
+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
quoted
Guenter
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help