Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3163190pxv; Sun, 4 Jul 2021 09:36:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyKlrHM7UBPIIaH8ampJTb9NsEpiWoSfHAzEsNzjFG4qcs/Z7+C9S/H8uZpL6yJNE7UfSJf X-Received: by 2002:a05:6402:40c3:: with SMTP id z3mr10919316edb.375.1625416613879; Sun, 04 Jul 2021 09:36:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625416613; cv=none; d=google.com; s=arc-20160816; b=UJnLayhgpxjCieFBHIu4F+fUL39Q0rh1vjYFHJfHklJ0WVGKz7PYu8XwsjSHcvf8w/ s5FovYdkmOSvfMjzjWNecyiVMB4W+RJB2CyAMXXiiIiwRobNJ6zw6MNo3co1YUS49ITN yKVP301RZ4TgalsameJdF51M/eYqTujeSSyBXt7Q5nJN2/5xxsHJW6ES8ZQEowE7d1Ma SX/rcwJ7r9UP89w8IcLb3wer9Amq3wiC3G4bYRV8agRMfDUAXqMMZP5Uv5QgSCSWj2O/ JwOUXoVAoSAh6RNYVrhSXieW3jyMNH/M4L0dD7exCVrEV3S1upYUzxCrlQtg1kqzMApy xbHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=9lbe4c+8woZAyGkPphPjvKSHllDq1R7ryKA6OPWYEn0=; b=kYYx7cOnNNV0XwMMT8k/qX4KIFnO5JH+zj2w/5y1DHX9fozfz+sQDReZ7Gx65Zwgsj 4FD2QCuua3RoO0pQJUJGAwCsKc4EQ5230ZnxpXLI+wUc+DzTBN+x4lBSW8Z6DoG8edpW k2KHFJrdOm9Sq7jrEqWFWOmCx0ScbDWMqslvieU5lEniNcFIusG/f8/ztKgQ0wXUys4b l2ZMqFaE0JLbKthukYLnGWw9Qin4CGanPm6cpEozwEwqUCAyf5MlCCBNKi4rguzPI/jC b0sCvmfOgtxEderrGY4isc3z+C7MuUDiwooBRIlJX2DgsXbPZpmZsfIh6xYnJ2vbJTB8 7KzQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w23si8764506ejf.188.2021.07.04.09.36.16; Sun, 04 Jul 2021 09:36:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229575AbhGDQ05 (ORCPT + 99 others); Sun, 4 Jul 2021 12:26:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:41874 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229539AbhGDQ05 (ORCPT ); Sun, 4 Jul 2021 12:26:57 -0400 Received: from jic23-huawei (cpc108967-cmbg20-2-0-cust86.5-4.cable.virginm.net [81.101.6.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 468B8613E7; Sun, 4 Jul 2021 16:24:19 +0000 (UTC) Date: Sun, 4 Jul 2021 17:26:43 +0100 From: Jonathan Cameron To: Liam Beguin Cc: peda@axentia.se, lars@metafoo.de, pmeerw@pmeerw.net, linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org, devicetree@vger.kernel.org, robh+dt@kernel.org Subject: Re: [PATCH v3 03/10] iio: inkern: make a best effort on offset calculation Message-ID: <20210704172643.074cf8c6@jic23-huawei> In-Reply-To: <20210701010034.303088-4-liambeguin@gmail.com> References: <20210701010034.303088-1-liambeguin@gmail.com> <20210701010034.303088-4-liambeguin@gmail.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 30 Jun 2021 21:00:27 -0400 Liam Beguin wrote: > From: Liam Beguin > > iio_convert_raw_to_processed_unlocked() assumes the offset is an > integer. Make a best effort to get a valid offset value for fractional > cases without breaking implicit truncations. > > Fixes: 48e44ce0f881 ("iio:inkern: Add function to read the processed value") > Signed-off-by: Liam Beguin Looks good, but a few really minor comments / questions inline. Thanks, Jonathan > --- > drivers/iio/inkern.c | 36 +++++++++++++++++++++++++++++++----- > 1 file changed, 31 insertions(+), 5 deletions(-) > > diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c > index b69027690ed5..e1712c1099c5 100644 > --- a/drivers/iio/inkern.c > +++ b/drivers/iio/inkern.c > @@ -578,13 +578,39 @@ EXPORT_SYMBOL_GPL(iio_read_channel_average_raw); > static int iio_convert_raw_to_processed_unlocked(struct iio_channel *chan, > int raw, int *processed, unsigned int scale) > { > - int scale_type, scale_val, scale_val2, offset; > + int scale_type, scale_val, scale_val2; > + int offset_type, offset_val, offset_val2; > s64 raw64 = raw; > - int ret; > + int tmp; > > - ret = iio_channel_read(chan, &offset, NULL, IIO_CHAN_INFO_OFFSET); > - if (ret >= 0) > - raw64 += offset; > + offset_type = iio_channel_read(chan, &offset_val, &offset_val2, > + IIO_CHAN_INFO_OFFSET); > + if (offset_type >= 0) { > + switch (offset_type) { > + case IIO_VAL_INT: > + break; > + case IIO_VAL_INT_PLUS_MICRO: > + fallthrough; I'm fairly sure you don't need to mark fallthroughs in the case where there is nothing in the case statement at all. That case is assumed to be deliberate by the various static checkers. I am seeing a few examples as you have it here in kernel, but it certainly isn't particularly common so I'm assuming those where the result of people falsely thinking it was necessary or the outcomes of code changes in the surrounding code. > + case IIO_VAL_INT_PLUS_NANO: > + /* > + * Both IIO_VAL_INT_PLUS_MICRO and IIO_VAL_INT_PLUS_NANO > + * implicitely truncate the offset to it's integer form. > + */ > + break; > + case IIO_VAL_FRACTIONAL: > + tmp = offset_val / offset_val2; > + offset_val = tmp; What benefit do we get from the local variable? offset_val /= offset_val2; would be alternative. > + break; > + case IIO_VAL_FRACTIONAL_LOG2: > + tmp = offset_val / (1 << offset_val2); > + offset_val = tmp; > + break; > + default: > + return -EINVAL; > + } > + > + raw64 += offset_val; > + } > > scale_type = iio_channel_read(chan, &scale_val, &scale_val2, > IIO_CHAN_INFO_SCALE);