[PATCH v3 1/2] Documentation: bindings: Introduce scpi,sensors-scale
linux at roeck-us.net
Wed Mar 15 15:40:07 PDT 2017
On Wed, Mar 15, 2017 at 09:56:09PM +0100, Martin Blumenstingl wrote:
> On Wed, Mar 15, 2017 at 7:20 PM, Sudeep Holla <sudeep.holla at arm.com> wrote:
> > On 09/03/17 10:17, Carlo Caione wrote:
> >> From: Carlo Caione <carlo at endlessm.com>
> >> 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.
More information about the linux-arm-kernel