Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp113931pxa; Tue, 4 Aug 2020 00:43:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQ/rjI8Nm6AchTm7UgRmV2Fj1oV8QHt6mgkoWeWeqiy1vIKMBm2eGXhcTvTFHBbsQELngZ X-Received: by 2002:a17:906:b2d0:: with SMTP id cf16mr20044195ejb.476.1596527029995; Tue, 04 Aug 2020 00:43:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596527029; cv=none; d=google.com; s=arc-20160816; b=eeEiPNqBg49Yf2k/ENXG8ovaJtofqCrsHmiPUTtSJBmdUGWUwujTlosF7AAInFBLXG T0hl/gnuL4WhUG+1h/uS5naHAQYyWgD9mFH9IwdRw6ves62zFaDcn+GG/Q7fJpkNSJUr MbqjowN/9UfhPEywW6OSFrvCxMvSkzjsT2hedLmIX22dgpySgjtNZLD7ZgtCutswPW00 +q3FaBwNDSRxoorTRNPxtOMy7IWX/x2RdRRQzSk8XrjM0vDyELmkqFQ3puDNsWefhKuW ukRueKck9qO8qe563cSSOFYfuv2aiFLvw8LJDHs7M+tXDSeTUrr4XmtoygAQuYk+/kwR dCLw== 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 :references:in-reply-to:organization:message-id:date:subject:cc:to :from; bh=U8zqMzzKU5ZB5rQW3vOaeItRHejl6HP2JIGiJ7wCeUA=; b=A7nO6KT0iKl0/9p0jgWYxcv2ht43IhzcwvbsS9CyPh3SfikvSISLPMCew5pBSJXsH1 Y8kF93OIrpjNNTgjCgoOXfqzAOiONFJsnuaKLfYDa6oy8DmSIhs2HKkIVJGZKAGfa7S8 z1jwBs3W8sBp6+OypGMUJvutLArrfPxr+M3yTLFUNfyjDGD2RXZ6N8vLuCLhQjseTphl zmFrr1jzyJ71u527R5+89vnKsW/beyOg5aXrrjDdOo2w9D8ZNoORGuCvegC4ijYX6vU/ eQ0q9T1tsvpSjmvoIWQvVaZtw5gBcI3UpSoe32MrMcW3oN8//E7e0LMwc0WM3mC7yqzC bjqA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j7si8544686ejo.66.2020.08.04.00.43.27; Tue, 04 Aug 2020 00:43:49 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729950AbgHDHma (ORCPT + 99 others); Tue, 4 Aug 2020 03:42:30 -0400 Received: from mailout11.rmx.de ([94.199.88.76]:37719 "EHLO mailout11.rmx.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726808AbgHDHma (ORCPT ); Tue, 4 Aug 2020 03:42:30 -0400 Received: from kdin01.retarus.com (kdin01.dmz1.retloc [172.19.17.48]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout11.rmx.de (Postfix) with ESMTPS id 4BLRYF45jsz3ybM; Tue, 4 Aug 2020 09:42:25 +0200 (CEST) Received: from mta.arri.de (unknown [217.111.95.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by kdin01.retarus.com (Postfix) with ESMTPS id 4BLRY03tZlz2xNM; Tue, 4 Aug 2020 09:42:12 +0200 (CEST) Received: from n95hx1g2.localnet (192.168.54.102) by mta.arri.de (192.168.100.104) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 4 Aug 2020 09:40:12 +0200 From: Christian Eggers To: Andy Shevchenko CC: Rob Herring , Jonathan Cameron , Jonathan Cameron , "Hartmut Knaack" , Lars-Peter Clausen , "Peter Meerwald-Stadler" , linux-iio , devicetree , Linux Kernel Mailing List Subject: Re: [PATCH v5 2/2] iio: light: as73211: New driver Date: Tue, 4 Aug 2020 09:40:11 +0200 Message-ID: <2356337.HYKpEJ1Wej@n95hx1g2> Organization: Arnold & Richter Cine Technik GmbH & Co. Betriebs KG In-Reply-To: References: <20200802163735.76617-1-ceggers@arri.de> <20200802163735.76617-3-ceggers@arri.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [192.168.54.102] X-RMX-ID: 20200804-094212-4BLRY03tZlz2xNM-0@kdin01 X-RMX-SOURCE: 217.111.95.66 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sunday, 2 August 2020, 20:02:35 CEST, Andy Shevchenko wrote: > Thanks for an update, my comments below. Thanks for the review. Please see below for my questions. Best regards Christian > On Sun, Aug 2, 2020 at 7:40 PM Christian Eggers wrote: > > Datasheet: > > https://ams.com/documents/20143/36005/AS73211_DS000556_3-01.pdf/a65474c0- > > b302-c2fd-e30a-c98df87616df > Do we need the UUID after the document file name? I have send AMS an inquiry. Not sure whether I will get an answer. I will wait a few days until sending v6. > > +#define AS73211_OFFSET_TEMP (-66.9) > > +#define AS73211_SCALE_TEMP 0.05 > > In the kernel we don't do float arithmetic. How these are being used? Does this restriction also apply for compile time constants? I am quite sure that all calculations using these defines will be evaluated at compile time. If found a number of other places where probably the same is done: find . -name '*.c' | xargs grep "#define.*[0-9]\.[0-9]" | grep -v '"' | grep -v "\/\*.*[0-9]\.[0-9]" > > + *val2 = (AS73211_OFFSET_TEMP - (int)AS73211_OFFSET_TEMP) * > > 1000000; > > > > + *val2 = (AS73211_SCALE_TEMP - > > (int)AS73211_SCALE_TEMP) * 1000000; > Magic 1000000 multiplier. I think that in the context of IIO_VAL_INT_PLUS_MICRO this isn't quite magic. Using 1000000 directly seems quite usual: find drivers/iio/ -type f | xargs grep "val2 = .*1000000" > I think here you got them always 0. And to fix that you need to > redefine (with also units included in the name) above constants like > #define ..._OFFSET_TEMP_mC 66500 > ... _SCALE_TEMP_?? 50 a scale factor has no unit > > Consider to use definitions from > https://elixir.bootlin.com/linux/latest/source/include/linux/units.h There are only definition for milli celsius. For IIO_VAL_INT_PLUS_MICRO I would require micro celsius. If I have the freedom, I would keep it as it is. Else I would suggest the following: #define AS73211_OFFSET_TEMP_INT (-66) #define AS73211_OFFSET_TEMP_MICRO 900000 #define AS73211_SCALE_TEMP_INT 0 #define AS73211_SCALE_TEMP_MICRO 50000 > > + }} > > + > > + return -EINVAL; > > Make it default case. changed. Is there any benefit? My IDE's syntax checker now complains "No return, in a function returning non-void". But gcc is happy with this. > > + ret = devm_iio_device_register(dev, indio_dev); > > + if (ret < 0) > > + return ret; > > + > > + return 0; > > return devm_iio_device_register(); changed. I prefer the original pattern as it would produce less changed lines if something needs to inserted later.