From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bh-25.webhostbox.net ([208.91.199.152]:52487 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751416AbdCOWkL (ORCPT ); Wed, 15 Mar 2017 18:40:11 -0400 Date: Wed, 15 Mar 2017 15:40:07 -0700 From: Guenter Roeck To: Martin Blumenstingl Cc: Sudeep Holla , Carlo Caione , jdelvare@suse.com, linux-hwmon@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux@endlessm.com, punit.agrawal@arm.com, robh+dt@kernel.org, devicetree@vger.kernel.org, Carlo Caione Subject: Re: [PATCH v3 1/2] Documentation: bindings: Introduce scpi,sensors-scale Message-ID: <20170315224007.GA14084@roeck-us.net> References: <20170309101759.18081-1-carlo@caione.org> <20170309101759.18081-2-carlo@caione.org> <57ff035a-b462-6f5d-0100-051e99e9a2b6@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-hwmon-owner@vger.kernel.org List-Id: linux-hwmon@vger.kernel.org On Wed, Mar 15, 2017 at 09:56:09PM +0100, Martin Blumenstingl wrote: > On Wed, Mar 15, 2017 at 7:20 PM, Sudeep Holla wrote: > > > > > > On 09/03/17 10:17, Carlo Caione wrote: > >> From: Carlo Caione > >> > >> 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