Thread (7 messages) 7 messages, 4 authors, 2017-03-15

[PATCH v3 1/2] Documentation: bindings: Introduce scpi,sensors-scale

From: linux@roeck-us.net (Guenter Roeck)
Date: 2017-03-15 22:40:07
Also in: linux-amlogic, linux-devicetree, linux-hwmon

On Wed, Mar 15, 2017 at 09:56:09PM +0100, Martin Blumenstingl wrote:
On Wed, Mar 15, 2017 at 7:20 PM, Sudeep Holla [off-list ref] wrote:
quoted

On 09/03/17 10:17, Carlo Caione wrote:
quoted
From: Carlo Caione <redacted>

Document the new property `scpi,sensors-scale` used by the hwmon-scpi
driver to convert the sensor readings to the correct / expected scale.
I am fine with DT bindings if DT maintainers agree with having one but I
would like to add couple of points to get their feedback:

1. ARM recognized the drawbacks of SCPI which started informally with
   ARM Ltd platforms and got adopted by few vendors. It's now being
   worked on and a much better and scalable replacement protocol is
   being discussed with vendors now. So future enhancement to this SCPI
   protocol is unlikely.

2. AmLogic has diverted from base protocol in many ways and most of them
   are handled with just compatible so far without any need for
   additional bindings. Can we avoid it ?

So based on these, I prefer not to add more bindings to handle such
deviations but make it just AmLogic specific.
could you please share your idea where this "Amlogic specific
implementation" fits best?
- in firmware/arm_scpi to keep a contract (for example: millicelsius)
to everyone who reads a temperature sensor for example
- or in hwmon/scpi-hwmon
So far the assumption was that it would be in hwmon. I don't mind for it
to be elsewhere, but I would think that the presence or non-presence
of a devicetree property should not affect or change the implementation.

Thanks,
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