Received: by 2002:a05:7412:b130:b0:e2:908c:2ebd with SMTP id az48csp2196308rdb; Mon, 20 Nov 2023 05:03:13 -0800 (PST) X-Google-Smtp-Source: AGHT+IEImWSFfP8DRfCsVua3SDVh23abuD+2n0W85AwJ02v8hMj3ZGPRbnOMGXjEhGNjHWux9K03 X-Received: by 2002:a17:903:1210:b0:1ce:5f67:cfd3 with SMTP id l16-20020a170903121000b001ce5f67cfd3mr5626778plh.18.1700485392654; Mon, 20 Nov 2023 05:03:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700485392; cv=none; d=google.com; s=arc-20160816; b=aJ/JzBV5w3nkacLD2Tpe8CrmbHoOKfop1UV2tehfp0OJo5TCKLko68PfhOJEfQp7Vc JmM2j0dbvsGwPAn6V2qYp+yZ//wNfaPLuSbnGYcWAVIGS+iRCnn50XqOEHTRbhDgszkX 5Ytf0yRSDF2uO51XCzFktJIHj+coVSNZCbQjiU7XYb3zR7nM1sfLdIQu7TNoC2EQ5kyO jNUxoqtnfiU96FUyG09A3DstsC2F7n+vIthbqMh9hGdvgI6R8U37NAgVk6yVzHU+/4vw 7Sh/GLQ94pjwtl0+inuF0RVTtCjN8CUAXKCMzYXCc/Qg1ZdBCubYNhM5fI89j36Lz/Cd +zow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=M2PYiKV+zB2GRsBT2jXAeskytEH3bHJYM+L6lJSq5zA=; fh=8hLf8JgDtZul9jrRqQvZF7sfUaEiG8a+w5FO+ttbP6g=; b=xVz6W8xdR3okTy6KBdaj7ood6hMFRAUoh3Ij6MmIyaCUQCNv5ndwhbH1SMYP24nXNT /EF6X76+oUEusYVbKkwgHlP2IUrw21cRPjwQB0Q2ZUgkAyUdhX3kSwhtD8ZihdEc7lSB 6csrPsCLwF2SeQgdv/tSYrLeGIiZyi+bbfmvFAhT/s/l9uro1uYs/gazI00qQjLHCCDV 2lPi4QNYmLOfEGoRbja0diyOigPqCg6o3fCKO42hMioIUlCd3lWMs/U/kmyMJn+/sStT e0WESw7k2GbdtLJOYTcMxymoIGadLgyX20nQZr365zb534UVoNyiGdb+uq5ydEruHtlh LygA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 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 groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id d12-20020a631d0c000000b005c1b2e37aeasi8110779pgd.384.2023.11.20.05.03.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Nov 2023 05:03:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 99CCD807F2B7; Mon, 20 Nov 2023 05:01:12 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232128AbjKTNA6 (ORCPT + 99 others); Mon, 20 Nov 2023 08:00:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231961AbjKTNA4 (ORCPT ); Mon, 20 Nov 2023 08:00:56 -0500 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 282119C; Mon, 20 Nov 2023 05:00:53 -0800 (PST) X-IronPort-AV: E=McAfee;i="6600,9927,10899"; a="4794400" X-IronPort-AV: E=Sophos;i="6.04,213,1695711600"; d="scan'208";a="4794400" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2023 05:00:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10899"; a="801163675" X-IronPort-AV: E=Sophos;i="6.04,213,1695711600"; d="scan'208";a="801163675" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga001.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2023 05:00:46 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.97) (envelope-from ) id 1r53tK-0000000FYIP-0fKV; Mon, 20 Nov 2023 15:00:42 +0200 Date: Mon, 20 Nov 2023 15:00:41 +0200 From: Andy Shevchenko To: mitrutzceclan Cc: linus.walleij@linaro.org, brgl@bgdev.pl, linux-gpio@vger.kernel.org, Lars-Peter Clausen , Jonathan Cameron , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Michael Walle , Arnd Bergmann , ChiaEn Wu , Niklas Schnelle , Leonard =?iso-8859-1?Q?G=F6hrs?= , Mike Looijmans , Haibo Chen , Hugo Villeneuve , Ceclan Dumitru , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/2] iio: adc: ad7173: add AD7173 driver Message-ID: References: <20231116134655.21052-1-user@HYB-hhAwRlzzMZb> <20231116134655.21052-2-user@HYB-hhAwRlzzMZb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231116134655.21052-2-user@HYB-hhAwRlzzMZb> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Mon, 20 Nov 2023 05:01:13 -0800 (PST) On Thu, Nov 16, 2023 at 03:46:55PM +0200, mitrutzceclan wrote: > From: Dumitru Ceclan > > The AD7173 family offer a complete integrated Sigma-Delta ADC solution > which can be used in high precision, low noise single channel > applications or higher speed multiplexed applications. The Sigma-Delta > ADC is intended primarily for measurement of signals close to DC but also > delivers outstanding performance with input bandwidths out to ~10kHz. ... > + help > + Say yes here to build support for Analog Devices AD7173 and similar ADC > + (currently supported: AD7172-2, AD7173-8, AD7175-2, AD7176-2). This is hard to maintain, list it one model per a single line. > + To compile this driver as a module, choose M here: the module will be > + called ad7173. ... + array_size.h > +#include > +#include > +#include This is guaranteed to be included by one from the above (don't remember by heart which one or even both). + container_of.h > +#include > +#include > +#include > +#include > +#include > +#include How is this being used (as not a proxy)? > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include ... > +#define AD7173_CH_ADDRESS(pos, neg) \ > + (FIELD_PREP(AD7173_CH_SETUP_AINPOS_MASK, pos) |\ Space before \ here and everywhere else in multi-line definitions. > + FIELD_PREP(AD7173_CH_SETUP_AINNEG_MASK, neg)) ... > +#define AD7173_VOLTAGE_INT_REF_MICROV 2500000 MICROV --> uV (yes, with small letter), it's a common use for Amperes, Volts, etc. ... > +struct ad7173_channel_config { > + bool live; > + u8 cfg_slot; > + /* Following fields are used to compare equality. Bipolar must be first */ > + bool bipolar; > + bool input_buf; > + u8 odr; > + u8 ref_sel; If you group better by types, it might save a few bytes on the architectures / compilers where bool != byte. > +}; ... > + st->reg_gpiocon_regmap = devm_regmap_init_spi(st->sd.spi, &ad7173_regmap_config); > + if (IS_ERR(st->reg_gpiocon_regmap)) { > + return dev_err_probe(dev, PTR_ERR(st->reg_gpiocon_regmap), > + "Unable to init regmap\n"); > + } {} are not needed, can also be written as st->reg_gpiocon_regmap = devm_regmap_init_spi(st->sd.spi, &ad7173_regmap_config); ret = PTR_ERR_OR_ZERO(st->reg_gpiocon_regmap); if (ret) return dev_err_probe(dev, ret, "Unable to init regmap\n"); ... > + st->gpio_regmap = devm_gpio_regmap_register(dev, &gpio_regmap); > + if (IS_ERR(st->gpio_regmap)) { > + return dev_err_probe(dev, PTR_ERR(st->gpio_regmap), > + "Unable to init gpio-regmap\n"); > + } Ditto. ... > +static struct ad7173_channel_config *ad7173_find_live_config > + (struct ad7173_state *st, struct ad7173_channel_config *cfg) This is strange indentation. Perhaps static struct ad7173_channel_config * ad7173_find_live_config(struct ad7173_state *st, struct ad7173_channel_config *cfg) ? ... > + offset = offsetof(struct ad7173_channel_config, cfg_slot) + > + sizeof(cfg->cfg_slot); Isn't it a offsetofend() from stddef.h? > + cmp_size = sizeof(*cfg) - offset; sizeof_field() from the above mentioned header? ... > + for (i = 0; i < st->num_channels; i++) { > + cfg_aux = &st->channels[i].cfg; > + > + if (cfg_aux->live && !memcmp(&cfg->bipolar, &cfg_aux->bipolar, > + cmp_size)) I would split this on logic operator, it will be easier to read. > + return cfg_aux; > + } ... > + free_cfg_slot = find_first_zero_bit(st->cfg_slots_status, > + st->info->num_configs); > + if (free_cfg_slot == st->info->num_configs) > + free_cfg_slot = ad7173_free_config_slot_lru(st); > + > + set_bit(free_cfg_slot, st->cfg_slots_status); > + cfg->cfg_slot = free_cfg_slot; Looks like reinvention of IDA. ... > + struct ad7173_state *st = iio_priv(indio_dev); > + unsigned int id; > + u8 buf[AD7173_RESET_LENGTH]; > + int ret; Reversed xmas tree order? struct ad7173_state *st = iio_priv(indio_dev); u8 buf[AD7173_RESET_LENGTH]; unsigned int id; int ret; ... > + return vref / (MICRO/MILLI); What does the denominator mean and why you can't simply use MILL? ... > + if (ch->cfg.bipolar) > + /* (1<<31) is UB for a 32bit channel */ > + *val = (chan->scan_type.realbits == 32) ? > + INT_MIN : > + -(1 << (chan->scan_type.realbits - 1)); So, what's the issue to use BIT() which has no such issue with UB? > + else > + *val = 0; ... > + *val = st->info->sinc5_data_rates[reg] / (MICRO/MILLI); > + *val2 = (st->info->sinc5_data_rates[reg] % MILLI) * (MICRO/MILLI); Same Q about denominator. ... > + case IIO_CHAN_INFO_SAMP_FREQ: > + freq = val * MILLI + val2 / MILLI; > + Unneeded blank line. > + for (i = 0; i < st->info->num_sinc5_data_rates - 1; i++) { > + if (freq >= st->info->sinc5_data_rates[i]) > + break; > + } > + > + cfg = &st->channels[chan->address].cfg; > + cfg->odr = i; > + > + if (!cfg->live) > + break; > + > + ret = ad_sd_read_reg(&st->sd, AD7173_REG_FILTER(cfg->cfg_slot), 2, ®); > + if (ret) > + break; > + reg &= ~AD7173_FILTER_ODR0_MASK; > + reg |= FIELD_PREP(AD7173_FILTER_ODR0_MASK, i); > + ret = ad_sd_write_reg(&st->sd, AD7173_REG_FILTER(cfg->cfg_slot), 2, reg); > + break; ... > +static int ad7173_update_scan_mode(struct iio_dev *indio_dev, > + const unsigned long *scan_mask) > +{ > + struct ad7173_state *st = iio_priv(indio_dev); > + int i, ret = 0; Use the 0 directly... > + > + for (i = 0; i < indio_dev->num_channels; i++) { > + if (test_bit(i, scan_mask)) > + ret = ad7173_set_channel(&st->sd, i); > + else > + ret = ad_sd_write_reg(&st->sd, AD7173_REG_CH(i), 2, 0); > + > + if (ret < 0) > + return ret; > + } > + > + return ret; ...here. > +} > + chan_arr = devm_kcalloc(dev, sizeof(*chan_arr), num_channels, > + GFP_KERNEL); One line. > + if (!chan_arr) > + return -ENOMEM; ... > + if (fwnode_property_read_u32(child, "adi,reference-select", &ref_sel)) > + ref_sel = AD7173_SETUP_REF_SEL_INT_REF; if is redundant. ref_sel = AD7173_SETUP_REF_SEL_INT_REF; fwnode_property_read_u32(child, "adi,reference-select", &ref_sel); -- With Best Regards, Andy Shevchenko