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 58079C001B0 for ; Tue, 8 Aug 2023 17:19:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234412AbjHHRTk (ORCPT ); Tue, 8 Aug 2023 13:19:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233090AbjHHRS5 (ORCPT ); Tue, 8 Aug 2023 13:18:57 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 404B88CA7; Tue, 8 Aug 2023 09:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691510865; x=1723046865; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=R6UzZPmeddLD5E78VuDAI1PCQFG215xuKvwMFArd0fs=; b=EHy+Hn0ktZWdBtZqAg1pcup75rcH10V0FYUgR7Q8LRrbHTck2yypR142 iA8KilkE5OM5+g5korQjyEzmnLd0nkmtG0x4FX/A7MmRSKC8qKiJfRFZ7 W5OrQ8lNPG97md6zJNei6K/TWlEb8V+51A8cQl9qcKQSP4rMWZJxxOtz0 LnuWjj772+T3AslKe9+P0pqY1OHoI/Dqg4/tpPcKikJqum+BHM2LH9RwI 10vpdOlDZ9UjuIqWiTfR9tMdNU4s0ai0d47FMtz0dxkXDsdVv27dnpU2j OQtOglCi6Tob8JfVma99qjeTb5WzkoLRlmSBrh9hrUMgNPVlUa4ewzgfI w==; X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="351138159" X-IronPort-AV: E=Sophos;i="6.01,156,1684825200"; d="scan'208";a="351138159" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Aug 2023 07:23:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="821390354" X-IronPort-AV: E=Sophos;i="6.01,156,1684825200"; d="scan'208";a="821390354" Received: from smile.fi.intel.com ([10.237.72.54]) by FMSMGA003.fm.intel.com with ESMTP; 08 Aug 2023 07:23:42 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1qTNca-00BeUL-0J; Tue, 08 Aug 2023 17:23:40 +0300 Date: Tue, 8 Aug 2023 17:23:39 +0300 From: Andy Shevchenko To: Marcus Folkesson Cc: Kent Gustavsson , Jonathan Cameron , Lars-Peter Clausen , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Cosmin Tanislav , Arnd Bergmann , ChiYuan Huang , Haibo Chen , Ramona Bolboaca , Ibrahim Tilki , ChiaEn Wu , William Breathitt Gray , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 4/4] iio: adc: mcp3911: add support for the whole MCP39xx family Message-ID: References: <20230808110432.240773-1-marcus.folkesson@gmail.com> <20230808110432.240773-4-marcus.folkesson@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230808110432.240773-4-marcus.folkesson@gmail.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org On Tue, Aug 08, 2023 at 01:04:32PM +0200, Marcus Folkesson wrote: > Microchip does have many similar chips, add support for those. ... > help > - Say yes here to build support for Microchip Technology's MCP3911 > - analog to digital converter. > + Say yes here to build support for Microchip Technology's MCP3910, > + MCP3911, MCP3912, MCP3913, MCP3914, MCP3918 and MCP3919 > + analog to digital converters. For maintenance this can be written as Say yes here to build support for one of the following Microchip Technology's analog to digital converters: MCP3910, MCP3911, MCP3912, MCP3913, MCP3914, MCP3918, MCP3919 > This driver can also be built as a module. If so, the module will be > called mcp3911. ... > +#define MCP3910_OFFCAL(x) (MCP3910_REG_OFFCAL_CH0 + x * 6) Inconsistent macro implementation, i.e. you need to use (x). ... > +static int mcp3910_get_osr(struct mcp3911 *adc, int *val) > +{ > + int ret, osr; Strictly speaking osr can't be negative, otherwise it's a UB below. u32 osr = FIELD_GET(MCP3910_CONFIG0_OSR, *val); int ret; and why val is int? > + ret = mcp3911_read(adc, MCP3910_REG_CONFIG0, val, 3); > + if (ret) > + return ret; > + > + osr = FIELD_GET(MCP3910_CONFIG0_OSR, *val); > + *val = 32 << osr; > + return ret; > +} ... > +static int mcp3910_set_osr(struct mcp3911 *adc, int val) > +{ > + int osr; > + > + osr = FIELD_PREP(MCP3910_CONFIG0_OSR, val); Can be on one line. > + return mcp3911_update(adc, MCP3910_REG_CONFIG0, > + MCP3910_CONFIG0_OSR, osr, 3); > +} ... > +static int mcp3911_set_osr(struct mcp3911 *adc, int val) > +static int mcp3911_get_osr(struct mcp3911 *adc, int *val) As per above comments. ... > + if (adc->vref) { > + dev_dbg(&adc->spi->dev, "use external voltage reference\n"); > + regval |= FIELD_PREP(MCP3910_CONFIG1_VREFEXT, 1); > + } else { > + dev_dbg(&adc->spi->dev, > + "use internal voltage reference (1.2V)\n"); As per previous patch comments dev_dbg(dev, "use internal voltage reference (1.2V)\n"); > + regval |= FIELD_PREP(MCP3910_CONFIG1_VREFEXT, 0); > + } ... > + if (adc->clki) { > + dev_dbg(&adc->spi->dev, "use external clock as clocksource\n"); > + regval |= FIELD_PREP(MCP3910_CONFIG1_CLKEXT, 1); > + } else { > + dev_dbg(&adc->spi->dev, > + "use crystal oscillator as clocksource\n"); Ditto. > + regval |= FIELD_PREP(MCP3910_CONFIG1_CLKEXT, 0); > + } ... > + if (device_property_read_bool(&adc->spi->dev, "microchip,data-ready-hiz")) This also becomes shorter. One trick to make it even shorter: if (device_property_present(dev, "microchip,data-ready-hiz")) > + regval |= FIELD_PREP(MCP3910_STATUSCOM_DRHIZ, 0); > + else > + regval |= FIELD_PREP(MCP3910_STATUSCOM_DRHIZ, 1); ... > + ret = device_property_read_u32(&spi->dev, "microchip,device-addr", &adc->dev_addr); I would move it after the comment. It will be more visible what we are expecting and what the legacy is. > + /* > + * Fallback to "device-addr" due to historical mismatch between > + * dt-bindings and implementation. > + */ ret = device_property_read_u32(dev, "microchip,device-addr", &adc->dev_addr); > if (ret) > - return ret; > + device_property_read_u32(&spi->dev, "device-addr", &adc->dev_addr); > + if (adc->dev_addr > 3) { > + dev_err(&spi->dev, > + "invalid device address (%i). Must be in range 0-3.\n", > + adc->dev_addr); > + return -EINVAL; return dev_err_probe(...); > + } ... > + dev_dbg(&spi->dev, "use device address %i\n", adc->dev_addr); Is it useful? -- With Best Regards, Andy Shevchenko