From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0CF39C433F5 for ; Sat, 14 May 2022 15:06:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233376AbiENPG0 (ORCPT ); Sat, 14 May 2022 11:06:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229727AbiENPGZ (ORCPT ); Sat, 14 May 2022 11:06:25 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 498C662E6; Sat, 14 May 2022 08:06:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 01235B808D4; Sat, 14 May 2022 15:06:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B4EAC340EE; Sat, 14 May 2022 15:06:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652540780; bh=p3KZwj8QpXKMJyG0Wif6t1Ig4rs3bBbnm+AnwQIxoC0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aXT8Im941oiy6DZ75RNM70Nk312UHwJXZgZ6y8OtVhAgWN44efTKLeSVRj2QbiVzw VTIhLlJoJ9MUxNUOjFKox22Y9JGUWspxe1JdYy5lWplLBqAM5Q8/qN9gdRoMEO33PH QX03zUTTB7hK6cggqYpwtJYV8/mV3MgncgtiQCCEKeQ2GraTlPcqegnOzts+k41bd4 /e+v9k0DJxgs/MPl6qaFD6Ysb8RhMyMNbKP0JKJWsksKCcQqgflstPWnyhL4JwG40w tyfXxL84eMoJhZHePQUlGdY8g7VfKBR+ywWQ2MbpoLj7YFANkHehBoELVyCn5e95tB aFAgS6H5IHN2Q== Date: Sat, 14 May 2022 16:14:56 +0100 From: Jonathan Cameron To: Alexandru Ardelean Cc: LI Qingwu , Lars-Peter Clausen , mchehab+huawei@kernel.org, linux-iio , LKML Subject: Re: [PATCH V1 1/5] iio: accel: bmi088: Modified the scale calculate Message-ID: <20220514161456.7de8915d@jic23-huawei> In-Reply-To: References: <20220509134629.440965-1-Qing-wu.Li@leica-geosystems.com.cn> <20220509134629.440965-2-Qing-wu.Li@leica-geosystems.com.cn> X-Mailer: Claws Mail 4.1.0 (GTK 3.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-iio@vger.kernel.org On Tue, 10 May 2022 09:01:20 +0300 Alexandru Ardelean wrote: > On Mon, May 9, 2022 at 4:46 PM LI Qingwu > wrote: > > > > The units after application of scale are 100*m/s^2, > > The scale calculation is only for the device > > with the range of 3, 6, 12, and 24g, > > but some other chips have a range of 2, 4, 6, and 8g. > > > > Modified the formula to a scale list. > > The scales in the list are calculated by 1/sensitivity*9.8. > > The new units after the application of scale are m/s^2. > > > > Signed-off-by: LI Qingwu > > --- > > drivers/iio/accel/bmi088-accel-core.c | 12 +++++++----- > > 1 file changed, 7 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/iio/accel/bmi088-accel-core.c b/drivers/iio/accel/bmi088-accel-core.c > > index a06dae5c971d..0c58ffdd00e3 100644 > > --- a/drivers/iio/accel/bmi088-accel-core.c > > +++ b/drivers/iio/accel/bmi088-accel-core.c > > @@ -119,6 +119,7 @@ struct bmi088_accel_chip_info { > > u8 chip_id; > > const struct iio_chan_spec *channels; > > int num_channels; > > + const int scale_table[4][2]; > > }; > > > > struct bmi088_accel_data { > > @@ -280,6 +281,7 @@ static int bmi088_accel_read_raw(struct iio_dev *indio_dev, > > struct bmi088_accel_data *data = iio_priv(indio_dev); > > struct device *dev = regmap_get_device(data->regmap); > > int ret; > > + int reg; > > > > switch (mask) { > > case IIO_CHAN_INFO_RAW: > > @@ -330,13 +332,12 @@ static int bmi088_accel_read_raw(struct iio_dev *indio_dev, > > return ret; > > > > ret = regmap_read(data->regmap, > > - BMI088_ACCEL_REG_ACC_RANGE, val); > > + BMI088_ACCEL_REG_ACC_RANGE, ®); > > Curios: do we need to validate the value of `reg` here? > If it goes outside of the 0...3 range, I can see a bit of access > violation (kernel panic) happening. > > > if (ret) > > goto out_read_raw_pm_put; > > - > > - *val2 = 15 - (*val & 0x3); > > - *val = 3 * 980; > > - ret = IIO_VAL_FRACTIONAL_LOG2; > > Not sure what the policy is about changing this now. > I'll leave this to Jonathan. It shouldn't be a problem as userspace ABI is a decimal string either way. Only impact might be on precision and those tend to be minor. > > > + *val = data->chip_info->scale_table[reg][0]; > > + *val2 = data->chip_info->scale_table[reg][1]; > > + ret = IIO_VAL_INT_PLUS_MICRO; > > > > goto out_read_raw_pm_put; > > default: > > @@ -432,6 +433,7 @@ static const struct bmi088_accel_chip_info bmi088_accel_chip_info_tbl[] = { > > .chip_id = 0x1E, > > .channels = bmi088_accel_channels, > > .num_channels = ARRAY_SIZE(bmi088_accel_channels), > > + .scale_table = {{0, 897}, {0, 1795}, {0, 3590}, {0, 7179}}, > > I like the idea of this scale_table. > It makes things easier to see (what's happening) without looking into > the datasheet much. > > > }, > > }; > > > > -- > > 2.25.1 > >