Received: by 2002:ab2:6857:0:b0:1ef:ffd0:ce49 with SMTP id l23csp2920358lqp; Mon, 25 Mar 2024 13:07:06 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCU82DXoej2SBkm5uUB5Vob51bZhuBolraayyoBBcq4E6fvBRNOGkg7gLa70k5QzDg6UxTgic5YP8wy1mSXet9Jz9e+QLJ5Z8Cw18lOehA== X-Google-Smtp-Source: AGHT+IFIT4gpvpU0l4THZbHPowCwPYeW77tVyncMVTa8ccvfGTclPOwhz9ZEhD/YMVVRlGwT3CP5 X-Received: by 2002:a37:c441:0:b0:78a:2f75:9100 with SMTP id h1-20020a37c441000000b0078a2f759100mr890851qkm.26.1711397226024; Mon, 25 Mar 2024 13:07:06 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1711397226; cv=pass; d=google.com; s=arc-20160816; b=cj6D95FLN1aZ2AczsUA1MwCOOgTWQHq53Ryq6x26dGcCiREOwkOfSm4NDddesISGXE YW9W5w3V59if0HLcmJ79bgJ8bWiIqIDnlpQaAomRWsGMqvugDSk8/nAXFK855oFhJUBr dsQQe0xCbD7Slemle37g/7GGCJkVwlKfFg7/cTRuPf96lVmjk49wjQPEKwwPd3Y75O1Z Uj2s1JZSQdag8nrsH/GUx6fnkXSYLTWRc5vM69rHNnHYvKFfyNxaUafEVCPQ6IZaBjA/ jdR4CmG7LA3/q04cNFYjGyUuB1WR4nux+CT9oREIfLG0sLDkfiKUx3CE2AVdskyNIfZB jBdg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=7hprFvaQP2HFE/aGNLV5iRrvp0HpvkT+0UG8akuFzUY=; fh=uZFYkvryVrO59A/HObEYsRxlVtQ1OJqZHkMjG4t38RI=; b=s0Q4SSbmSWe4NyHgmgWXdq3R3JbE4m9UDYYOgtBS23Vk1V6h9ItiPg3oajTTEwiEFs VZ0nq41O9pbq3EaUcJxVKQddTvl5L3v+TAwYTpnMsiZrwiIMj10pzcal3DKjU7X82OX4 AwOUbmb6qg2eBZZio3VIWing3xo3KtRj+E09ep567WU0EIa9vErjsDTbXiQC7+EjtWv3 +rOgzSJtMXMZQ+0Bh64vxXw70Ho2q1MwW8Qh7pT2oPjdFtjXVj9CsBo0K5r1V7q+81x6 29X73pVt5lDwiJ9WTJHFowKDJazfuFM4dGV9OMu75mDKh7AMXqJBYUM7ULIUVZZ2R13q f14Q==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="oCq/30nk"; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-117886-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-117886-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id h20-20020a05620a401400b00789e72be3b0si6911073qko.607.2024.03.25.13.07.05 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Mar 2024 13:07:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-117886-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="oCq/30nk"; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-117886-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-117886-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 3E8BD1C3F445 for ; Mon, 25 Mar 2024 20:06:54 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1AFCF41238; Mon, 25 Mar 2024 20:06:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oCq/30nk" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3ABB43E468; Mon, 25 Mar 2024 20:06:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711397203; cv=none; b=tPd1ZBkKWy+2bHebBbHJRRGwY0y3ADpk0xsbKGt2mRKnRthI8yn0yUZMW6sSyOci7HBKuQJlsiIMznBu7G14AGrxXz0Be2CiY5/0koPHtTUbUjehIfnwlmIP8CnBWBVmIWwizTj9SC2csnuwC3hW7x03v2e6ETlX3JcivN8X5w0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711397203; c=relaxed/simple; bh=TFyc7t7zAjF14Ku+RI2u7lJnCT2d4Wt2C2Ahw/P8HW0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZA503o6Sjtf+4PpQ5OY/uWXKtQj/9HynDDXksveRihUvlhSn3T9Z/WlJRMQdlTyMQ2+P/opCPkwVTqjh2eqh5hVXCvGrrxIk+lwL3wSx+7zp+38QecNGy7SEpPuqGxKg6r6WYeKdHbL+kI1CYxHlAnh05ifKCMJAs0uUPTpRPhs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oCq/30nk; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 855F5C433F1; Mon, 25 Mar 2024 20:06:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711397202; bh=TFyc7t7zAjF14Ku+RI2u7lJnCT2d4Wt2C2Ahw/P8HW0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oCq/30nkbitp5TaP/65h2LjOGxDs81MCvMY3Fqo3I76+1/BGnWdq1gGTuRLBUCZXi X22nB5Re7Rh3xEiZjLVqGBglCDSW1TPVhHfIVXmOhIr47oiANLUt0gkHGJbCefGE0J VckK+PFUZEWc4kxwZ6P+XYX9zPE/Pmc1Z857yQm4L8V//8XlRfoz0IK1mw5B/KsaJt 9Q5ZHatW8UI//Xcqvcole458xy8oeNpa5pkBnHOp97cD2WhxiyytGxj6rW75JTrQfh BGXCoY+hZsdt1Xam8ElbM4GqJ0nYzISvggIcey4++RpLlU68TZttccJzIc4UAX2ckX i0h+4XsZyaJJg== Date: Mon, 25 Mar 2024 20:06:25 +0000 From: Jonathan Cameron To: David Lechner , Mark Brown Cc: Julien Stephan , Lars-Peter Clausen , Michael Hennerich , Nuno =?UTF-8?B?U8Oh?= , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Liam Girdwood , linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, kernel test robot Subject: Re: [PATCH v5 4/7] iio: adc: ad7380: add support for pseudo-differential parts Message-ID: <20240325200625.5a07cec4@jic23-huawei> In-Reply-To: References: <20240319-adding-new-ad738x-driver-v5-0-ce7df004ceb3@baylibre.com> <20240319-adding-new-ad738x-driver-v5-4-ce7df004ceb3@baylibre.com> <20240324130135.35f4b0eb@jic23-huawei> X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > > + /* > > > + * pseudo-differential chips have common mode supplies for the negative > > > + * input pin. > > > + */ > > > + for (i = 0; i < st->chip_info->num_vcm_supplies; i++) { > > > + struct regulator *vcm; > > > + > > > + vcm = devm_regulator_get_optional(&spi->dev, > > > > Why optional? > > > > > + st->chip_info->vcm_supplies[i]); > > > + if (IS_ERR(vcm)) > > > > This will fail if it's not there, so I'm guessing you are using this to avoid > > getting to the regulator_get_voltage? If it's not present I'd rely on that > > failing rather than the confusing handling here. > > > > When the read of voltage wasn't in probe this would have resulted in a problem > > much later than initial setup, now it is, we are just pushing it down a few lines. > > > > Arguably we could have a devm_regulator_get_not_dummy() > > that had same implementation to as get_optional() but whilst it's called that > > I think it's confusing to use like this. > > Despite the misleading naming, I guess I am used to > devm_regulator_get_optional() by now having used it enough times. > Since it fails either way though, technically both ways seem fine so I > can't really argue for one over the other. > > But given that this is a common pattern in many IIO drivers, maybe we > make a devm_regulator_get_enable_get_voltage()? This would return the > voltage on success or an error code. (If the regulator subsystem > doesn't want this maybe we could have > devm_iio_regulator_get_enable_get_voltage()). > > If the dev_err_probe() calls were included in > devm_regulator_get_enable_get_voltage(), then the 10+ lines of code > here and in many other drivers to get the regulator, enable it, add > the reset action and get the voltage could be reduced to 3 lines. I like this proposal a lot. RFC, so it's visible outside the depths of this thread? Particularly good as it will keep the regulator opaque in the same fashion as devm_regulator_get_enabled() As you say, we have a 'lot' of instances of this (quick grep suggests > 50 in IIO alone and smaller numbers elsewhere). Jonathan > > > > > > + return dev_err_probe(&spi->dev, PTR_ERR(vcm), > > > + "Failed to get %s regulator\n", > > > + st->chip_info->vcm_supplies[i]); > > > + > > > + ret = regulator_enable(vcm); > > > + if (ret) > > > + return ret; > > > + > > > + ret = devm_add_action_or_reset(&spi->dev, > > > + ad7380_regulator_disable, vcm); > > > + if (ret) > > > + return ret; > > > + > > > + ret = regulator_get_voltage(vcm); > > > > I'd let this fail if we have a dummy regulator. > > > > > + if (ret < 0) > > > + return ret; > > > + > > > + st->vcm_mv[i] = ret / 1000; > > > + } > > > + >