Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp1183752pxb; Sun, 11 Apr 2021 10:12:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyr0bKLAFOeyR5LHL/ZcdQwOhq6UDRFM/zyXg8k+0xbh9NcbXKCffDBcjFnYzCs6ApX1sAU X-Received: by 2002:a63:e206:: with SMTP id q6mr22724380pgh.225.1618161163064; Sun, 11 Apr 2021 10:12:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618161163; cv=none; d=google.com; s=arc-20160816; b=b3zPxW587fNofd6+jiyE4EJ88foCrARRb3iY83plpKoo28qfTqKFkvQhusQiLb5a3X RQwjTiwbpN6FMROASE7kt1qOEjLVDKFE9SQLRbTAtzreS7lP2QiMtBhDdR0UR4KWeZnz HF/15Dylp/6zayykkGFh81ptdTRK9r5bMUMujfXpeTi8G79GoKIQS+inKUJsdmN4LEUL n7SMI2Nb6EzHE7FuLgaNKCS4N45urC5BfCo2d8U68k0JTzFro+twchWBlDDZAgXsaWba ngktuHjuXRs7GKevH2xiUpuKxCHaxHvWRWetNMRP3M78XiidgkC9GHFlPpZWNpPq7vgJ igaw== 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=2TTnspM6vEBs2j9wcxg7xg3CFmIB8e0iCInuhS+DcPs=; b=YbtcANEzYjV9Vga8Yg16bPzILKvXhlQMFzv5PwVoYYqNYbNHGLbEFxDUYlPUUJ74Ei RQeQXByqv5F++OZAOnXUSq9Dhl2OfLtY9cVoLCluvvnsoRiIFmMthGS0kzBB5HG1VV6g 5PgKK5s6JT82FChyb+Kuujvelxc8ird0yqtZj6pX0t/WhliH0AOHX4M051hfrSh+zGce ErSudZxADZMFUNQ/BVrzN/t+G8Iy/X55KusXb8dVdyug69RynoNkqfYNZQhkQB93/CEV tyCz3oynBaPlns9DizgzY13nwqkpBHjO3r54P3/5zlo+1LVmVNeByYTqPffLm7G8V2FT UXvg== 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 p11si10348832pjl.1.2021.04.11.10.12.31; Sun, 11 Apr 2021 10:12:43 -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 S235934AbhDKOyQ (ORCPT + 99 others); Sun, 11 Apr 2021 10:54:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:49804 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233822AbhDKOyP (ORCPT ); Sun, 11 Apr 2021 10:54:15 -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 78AFD60FF1; Sun, 11 Apr 2021 14:53:56 +0000 (UTC) Date: Sun, 11 Apr 2021 15:54:20 +0100 From: Jonathan Cameron To: Puranjay Mohan Cc: alexandru.ardelean@analog.com, devicetree@vger.kernel.org, knaack.h@gmx.de, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, lars@metafoo.de, andy.shevchenko@gmail.com Subject: Re: [PATCH v4 2/2] iio: temperature: add driver support for ti tmp117 Message-ID: <20210411155420.318e866e@jic23-huawei> In-Reply-To: <20210407182147.77221-3-puranjay12@gmail.com> References: <20210407182147.77221-1-puranjay12@gmail.com> <20210407182147.77221-3-puranjay12@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, 7 Apr 2021 23:51:47 +0530 Puranjay Mohan wrote: > TMP117 is a Digital temperature sensor with integrated Non-Volatile memory. > Add support for tmp117 driver in iio subsystem. > > Datasheet: https://www.ti.com/lit/gpn/tmp117 > Signed-off-by: Puranjay Mohan > Reviewed-by: Andy Shevchenko A few really small things in here that I tidied up whilst applying and running local build tests. Note that as IIO is effectively closed for the coming merge window, I'm queuing this up for the next cycle and it will be in linux-next after the merge window closes in about 3 weeks time. Thanks, Jonathan > +static int tmp117_read_raw(struct iio_dev *indio_dev, > + struct iio_chan_spec const *channel, int *val, > + int *val2, long mask) > +{ > + struct tmp117_data *data = iio_priv(indio_dev); > + s32 ret; > + > + switch (mask) { > + case IIO_CHAN_INFO_RAW: > + ret = i2c_smbus_read_word_swapped(data->client, > + TMP117_REG_TEMP); > + if (ret < 0) > + return ret; > + *val = sign_extend32(ret, 15); > + return IIO_VAL_INT; > + > + case IIO_CHAN_INFO_CALIBBIAS: > + ret = i2c_smbus_read_word_swapped(data->client, > + TMP117_REG_TEMP_OFFSET); > + if (ret < 0) > + return ret; > + *val = sign_extend32(ret, 15); > + return IIO_VAL_INT; > + > + case IIO_CHAN_INFO_SCALE: > + /* Conversion from 10s of uC to mC Totally trivial so I'll fix it whilst applying, but comment convention used in IIO is /* * Conversion > + * as IIO reports temperature in mC > + */ > + *val = TMP117_RESOLUTION_10UC / MICRODEGREE_PER_10MILLIDEGREE; > + *val2 = (TMP117_RESOLUTION_10UC % > + MICRODEGREE_PER_10MILLIDEGREE) * 100; > + > + return IIO_VAL_INT_PLUS_MICRO; > + > + default: > + return -EINVAL; > + } > +} > + > +static int tmp117_write_raw(struct iio_dev *indio_dev, > + struct iio_chan_spec const *channel, int val, > + int val2, long mask) > +{ > + struct tmp117_data *data = iio_priv(indio_dev); > + s16 off; > + > + switch (mask) { > + case IIO_CHAN_INFO_CALIBBIAS: > + off = clamp(val, S16_MIN, S16_MAX); With a C=1 W=1 build (sparse an lots of warnings) this causes problems because the S16_MIN and S16_MAX are as you might imagine s16 values whereas val is an int. I've added casts to force S16_MIN and S16_MAX to ints as well. > + if (off == data->calibbias) > + return 0; > + data->calibbias = off; > + return i2c_smbus_write_word_swapped(data->client, > + TMP117_REG_TEMP_OFFSET, off); > + > + default: > + return -EINVAL; > + } > +} ...