On Wed, Mar 01, 2017 at 07:45:50PM +0100, Carlo Caione wrote: > On Wed, Mar 1, 2017 at 6:56 PM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > > On Wed, Mar 01, 2017 at 04:57:00PM +0000, Punit Agrawal wrote: > > >> Another way to fix this would be to add optional properties to the scpi > >> sensors binding and use them instead. This could then be used to fixup > >> values reported to both thermal and hwmon. > >> > > > > Yes, this would be much more appropriate. > > What about something like: > > sensor-coefficients = <x1 y1 z1>, > <x2 y2 z2>, > ...; As mentioned before, I don't think 'slope' and 'offset' are well enough defined, so I would rather not use that approach. I don't know if there are DT examples on how to specify a translation from an arbitrary value to well-defined units; we could use that if it exists. Otherwise, we might just go with a combination of sensor class and the unit scale used for that sensor class. A simple approach might be something like scpi,sensor-scale = // pick preferred property name <0 1000>, <1 1000>, <2 1000>, <3 1000000>, <4 1000000>; or even simpler scpi,sensor-scale = <1000, 1000, 1000, 1000000, 1000000>; since the class index is really redundant. This would describe the units for the Juno ARM development platform. In your case, that would be something like scpi,sensor-scale = <1, 1000, 1000, 1000000, 1000000>; assuming that the other units are as expected (which may not be the case). Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html