Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4354435ybi; Tue, 11 Jun 2019 05:24:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqwwo2GoC2eWyE37OPsEhEDIIR6rQPg8DZ5cNbsbyLp/OxEeHTNoo2tNFQaID1wfUkayvsys X-Received: by 2002:a17:902:724:: with SMTP id 33mr73978422pli.49.1560255870119; Tue, 11 Jun 2019 05:24:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560255870; cv=none; d=google.com; s=arc-20160816; b=dgYqu50e29qI8MPH5OyiltJSJC6oe/qKYcfugCRqUu/B2sKS7Rn+gGC0KP3s5LmguO W6LFIekMlN8hpA7gPksPuSw/xBQrN5yriptXSiZAhvBZMY5wZa51dmJCGDx6lfU9L2Ob 7mRoT+p0q9iZiy1IqmT8XQGxBrw0pxSAqKkpJ35EeMXb+yqZ0Uc0SaWCIfBt7HiK2g9d MaQ3V4wxUVnob48jUMubbdCAWhZjV9Eo1kQpfjAuaWtZ8A7YCRNrFRUA7aPMy8n0tR9B qsRjSSkrfRQE4V+GZnhINDHaqLE3DKauTOGYpHX8o6L6r/4fIj5Uruz+I4FoJrSUyp6k wP7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=afaEIibvIE/9erZw7r59eP9gRVJPsu4zytcnodnt5qk=; b=Q13b+nh+wlMRwKeN+sqIAlbFcHX8XOZd4rAFoieTQ6o9E5c+v/8Sq0FQmhGqHJW2J2 Bm4kT1PwtLM9q+4/T/gU5Ar/YaTNxB6uCwzDNWMxwjjE9i/aGSO2jIA5XktjbvcH3pGK egd6nzhc/tYIKqfAF6qq+ZNJj7hUsRDx25jSjz6ub7zZKeDVFxPC/14TYPjoGL4uFdhz rRhy/oNHCyBTP06Nhf+a2yVwwOXLtSJN0hRJzoo9AVdUMXcdlpS5m3G3v00EJTT9uiyr JiaRzusJGUJBTk2KpAXr0Gbsm+ynhUAiRNbki30Gy8fX8dSSozqbs28mPybT04fH8gTf HN6A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r91si2368682pjb.61.2019.06.11.05.24.14; Tue, 11 Jun 2019 05:24:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403982AbfFKLoq convert rfc822-to-8bit (ORCPT + 99 others); Tue, 11 Jun 2019 07:44:46 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:18126 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2403960AbfFKLop (ORCPT ); Tue, 11 Jun 2019 07:44:45 -0400 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 54B027808EA8580B77F4; Tue, 11 Jun 2019 19:44:32 +0800 (CST) Received: from localhost (10.202.226.61) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.439.0; Tue, 11 Jun 2019 19:44:29 +0800 Date: Tue, 11 Jun 2019 12:44:17 +0100 From: Jonathan Cameron To: Peter Rosin CC: =?ISO-8859-1?Q?Myl=E8ne?= Josserand , "jic23@kernel.org" , "knaack.h@gmx.de" , "lars@metafoo.de" , "pmeerw@pmeerw.net" , "robh+dt@kernel.org" , "mark.rutland@arm.com" , "linux-iio@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "thomas.petazzoni@bootlin.com" Subject: Re: [PATCH v1 0/3] iio: afe: rescale: Add INFO_PROCESSED support Message-ID: <20190611124417.0000137a@huawei.com> In-Reply-To: <36890130-24ed-2200-1e8d-964612fee62d@axentia.se> References: <20190611095659.29845-1-mylene.josserand@bootlin.com> <36890130-24ed-2200-1e8d-964612fee62d@axentia.se> Organization: Huawei X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8BIT X-Originating-IP: [10.202.226.61] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 11 Jun 2019 11:02:14 +0000 Peter Rosin wrote: > On 2019-06-11 11:56, Myl?ne Josserand wrote: > > Hello everyone, > > > > You will find a small series that add the support of processed values > > for iio-rescale driver. > > Thanks to that, it is possible to read processed values in sysfs instead > > of getting only raw and scale values. > > > > Here is an example for a 3v3 voltage reading: > > # cat /sys/bus/iio/devices/iio\:device1/in_voltage0_scale > > 3.791015625 > > # cat /sys/bus/iio/devices/iio\:device1/in_voltage0_raw > > 879 > > # cat /sys/bus/iio/devices/iio\:device1/in_voltage0_input > > 3332 > > > > It is also possible to read directly the processed values using iio-hwmon > > driver (see example in patch03): > > > > # cat /sys/class/hwmon/hwmon0/in1_input > > 3328 > > > > I seperated my series in 3 patches: > > - Patch01: Move the scale conversion into a function to prepare the > > support of IIO_CHAN_INFO_PROCESSED. > > - Patch02: Add the support of IIO_CHAN_INFO_PROCESSED. > > - Patch03: Add an example of the use of hwmon and voltage-divider nodes > > in device-tree. > > > > If you have any feedbacks on it, I will be pleased to read them! > > > The last patch about hwmon has nothing to do with this series, and > should be possible as-is without any code changes. No? AFAICT, > iio_hwmon calls iio_read_channel_processed, which calls > iio_convert_raw_to_processed_unlocked in case IIO_CHAN_INFO_PROCESSES > is not handled by the driver. Is that not working? > > There is also libiio in userspace that provides the scale as a double > and makes the conversion to a processed value trivial, so the series > is really mostly about the convenience of having a human directly > seeing the processed value in sysfs. Right? > > If that is deemed valuable, then I think it should be fixed in a > central location, and not individually for each and every driver. > > Anyway, not my call, just stating my opinion, but those are the > reasons for me not adding a processed channel from the very beginning. I definitely want to fully understand the reasoning behind this proposal. My gut feeling is that it doesn't make sense a sit ends up with two interfaces to the same thing in userspace, which we generally want to avoid. It's really trivial to do the maths in userspace and often doing it in kernel is less accurate, or much more complex. Jonathan > > Cheers, > Peter > > > Best regards, > > Myl?ne > > > > Myl?ne Josserand (3): > > iio: afe: rescale: Move scale conversion to new function > > iio: afe: rescale: Add support of CHAN_INFO_PROCESSED > > dt-bindings: iio: afe: Add hwmon example > > > > .../bindings/iio/afe/voltage-divider.txt | 24 ++++++ > > drivers/iio/afe/iio-rescale.c | 96 ++++++++++++++++------ > > 2 files changed, 96 insertions(+), 24 deletions(-) > > >