Received: by 2002:a05:7412:2a8c:b0:e2:908c:2ebd with SMTP id u12csp260563rdh; Sat, 23 Sep 2023 09:10:58 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHHUPmlwt2REygS0k8EUvCR38QGK/4OT3DZ2w1HICs4XMuRewXEf1qpb7NWecPFuaThqpxS X-Received: by 2002:a05:6a20:1451:b0:15c:7223:7bb1 with SMTP id a17-20020a056a20145100b0015c72237bb1mr3357123pzi.20.1695485458193; Sat, 23 Sep 2023 09:10:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695485458; cv=none; d=google.com; s=arc-20160816; b=G6Jccr/EcqADeIn6ZtQUXb+3cmi0JxQdxIxUFP+eBpv8pu/cjaDq7YfBYGfnoGt4mm Ydg0pJa01hWraPIqe0y+/bUIkU5fLEhGulpwIvUEvf7mVVOR5WiCGGTQXgIQjWeSLYMa IReUdMVFlEg/vyLT7k//myRp7OKIrkC3+4JS3rNXmx4fVLrjTl6zeeZ4/TwEh8PzeCBQ EJuaLdC+bfYBWIrc9dM/XkR3Ia2kQZZ1YrCNhwQVasCsrME7wxOisCNf0mQ3XF71Db4k bix/CxsQYQDJ94O9bd5H+E8PyaLExbVW0hOym2bmWY779wCfGaCrICh091+sGjc5cBsb 7kGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=6apHpN5+f9PzpZ+iZJCHBJz20x7FAvnFYJIa9GV7SRY=; fh=/5xPoZbXxIhm5GdXt1NxqAJ8/sOnqKUP+sAyK8mg+5Q=; b=w4OBCRFQxPayBLGRnGCzy1lS4k6RyUKbMOOuqtJBgjBFkvv6BI+nMGuUZxKhbDHkFm IYhRcvr6AnGm4pMCojsXfkQ9k9tkyTRrNBuY40RuSyGJvU4ucFz+WKTo5YPGnnoflsmY mhvc+m0U3X0ViSavJZTjC1+b4f35tztWC3HKu9+rfAeyU2QqdFRq+NLNR9U3BNFaHrzR 0dXxSBlHp+PaH9vABGmVq6yhqQr2KmX/SF4IK+FkUOB14/MybyN+uc8Q5T5IgDlKisA2 2oa/j6OHJDVGBn16bFBHVCZK0/rmrixe+zW8WbasQHMUhhLj19OD9LM24rB47JERXrLQ HZIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bewilderbeest.net header.s=thorn header.b=Umws2Jc+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=bewilderbeest.net Return-Path: Received: from morse.vger.email (morse.vger.email. [23.128.96.31]) by mx.google.com with ESMTPS id fo10-20020a056a00600a00b0068fa57cc15bsi6116767pfb.124.2023.09.23.09.10.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Sep 2023 09:10:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31; Authentication-Results: mx.google.com; dkim=pass header.i=@bewilderbeest.net header.s=thorn header.b=Umws2Jc+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=bewilderbeest.net Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id AC6B2801CF9D; Sat, 23 Sep 2023 05:03:05 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231392AbjIWMDG (ORCPT + 99 others); Sat, 23 Sep 2023 08:03:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230458AbjIWMDF (ORCPT ); Sat, 23 Sep 2023 08:03:05 -0400 Received: from thorn.bewilderbeest.net (thorn.bewilderbeest.net [IPv6:2605:2700:0:5::4713:9cab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59770199 for ; Sat, 23 Sep 2023 05:02:59 -0700 (PDT) Received: from hatter.bewilderbeest.net (unknown [IPv6:2602:61:7e5d:5300::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: zev) by thorn.bewilderbeest.net (Postfix) with ESMTPSA id 09D075C9; Sat, 23 Sep 2023 05:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bewilderbeest.net; s=thorn; t=1695470579; bh=6apHpN5+f9PzpZ+iZJCHBJz20x7FAvnFYJIa9GV7SRY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Umws2Jc+X4fwRQCvyNmKIrjp25rasC6NsLsdASu/wQf3yWddV26XMeTNCja+8iy7v /B0IaejoBSRqQSth7ZSvpZSsUIoMOcl9liCwwmMQ4CUrDdSPDUtSxgE+WQF1NJWJX4 JUrHYrIbfYyU+datHDFNo7fubx5UAfnxOSmIS5dQ= Date: Sat, 23 Sep 2023 05:02:57 -0700 From: Zev Weiss To: Naresh Solanki Cc: broonie@kernel.org, Liam Girdwood , linux-kernel@vger.kernel.org Subject: Re: [RESEND PATCH] regulator: userspace-consumer: Retrieve supplies from DT Message-ID: <53bf617a-0a47-4c51-9738-6f6e6e520d99@hatter.bewilderbeest.net> References: <20230922090330.1570350-1-naresh.solanki@9elements.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20230922090330.1570350-1-naresh.solanki@9elements.com> X-Spam-Status: No, score=2.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.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 (morse.vger.email [0.0.0.0]); Sat, 23 Sep 2023 05:03:05 -0700 (PDT) X-Spam-Level: ** Hi Naresh, This looks basically alright to me, though a few suggested tweaks below... On Fri, Sep 22, 2023 at 02:03:29AM PDT, Naresh Solanki wrote: >From: Naresh Solanki > >Instead of hardcoding a single supply, retrieve supplies from DT. > >Signed-off-by: Naresh Solanki >--- > drivers/regulator/userspace-consumer.c | 43 ++++++++++++++++++++++++-- > 1 file changed, 40 insertions(+), 3 deletions(-) > >diff --git a/drivers/regulator/userspace-consumer.c b/drivers/regulator/userspace-consumer.c >index 97f075ed68c9..a3d3e1e6ca74 100644 >--- a/drivers/regulator/userspace-consumer.c >+++ b/drivers/regulator/userspace-consumer.c >@@ -115,11 +115,32 @@ static const struct attribute_group attr_group = { > .is_visible = attr_visible, > }; > >+#define SUPPLY_SUFFIX "-supply" >+#define SUPPLY_SUFFIX_LEN 7 I think 'strlen(SUPPLY_SUFFIX)' would be preferable to a numeric literal here; it's less fragile and the compiler can evaluate it at compile-time anyway (not that it's likely to be performance-critical in this context I'd expect). >+ >+static int get_num_supplies(struct platform_device *pdev) >+{ >+ struct property *prop; >+ int num_supplies = 0; >+ >+ for_each_property_of_node(pdev->dev.of_node, prop) { >+ const char *prop_name = prop->name; >+ int len = strlen(prop_name); >+ >+ if (len > SUPPLY_SUFFIX_LEN && >+ strcmp(prop_name + len - SUPPLY_SUFFIX_LEN, SUPPLY_SUFFIX) == 0) { >+ num_supplies++; >+ } Preferred coding style is to omit braces around single-line 'if' blocks. >+ } >+ return num_supplies; >+} >+ > static int regulator_userspace_consumer_probe(struct platform_device *pdev) > { > struct regulator_userspace_consumer_data tmpdata; > struct regulator_userspace_consumer_data *pdata; > struct userspace_consumer_data *drvdata; >+ struct property *prop; Looks like there's an extra space after 'struct' here. > int ret; > > pdata = dev_get_platdata(&pdev->dev); >@@ -131,11 +152,27 @@ static int regulator_userspace_consumer_probe(struct platform_device *pdev) > memset(pdata, 0, sizeof(*pdata)); > > pdata->no_autoswitch = true; >- pdata->num_supplies = 1; >- pdata->supplies = devm_kzalloc(&pdev->dev, sizeof(*pdata->supplies), GFP_KERNEL); >+ pdata->num_supplies = get_num_supplies(pdev); >+ >+ pdata->supplies = devm_kzalloc(&pdev->dev, pdata->num_supplies * >+ sizeof(*pdata->supplies), GFP_KERNEL); Splitting the multiplication across two lines like that isn't great readability-wise IMO; it might be better to just assign it to a variable and use that instead to make things fit nicely. > if (!pdata->supplies) > return -ENOMEM; >- pdata->supplies[0].supply = "vout"; >+ >+ for_each_property_of_node(pdev->dev.of_node, prop) { >+ const char *prop_name = prop->name; >+ int len = strlen(prop_name); >+ >+ if (len > SUPPLY_SUFFIX_LEN && >+ strcmp(prop_name + len - SUPPLY_SUFFIX_LEN, SUPPLY_SUFFIX) == 0) { Rather than duplicating this suffix-checking code, how about factoring out a helper function like prop_is_supply() or something to use both here and in get_num_supplies()? Or actually to make it integrate here a little more nicely, you could have something like 'size_t prop_supply_name(char*)', returning zero if it doesn't end with "-supply", and the length of the name before the suffix if it does, so that get_num_supplies() could use it as a boolean and the code below could use the length to determine the allocation size. >+ char *supply_name = devm_kzalloc(&pdev->dev, >+ len - SUPPLY_SUFFIX_LEN + 1, >+ GFP_KERNEL); >+ strscpy(supply_name, prop_name, len - SUPPLY_SUFFIX_LEN); >+ supply_name[len - SUPPLY_SUFFIX_LEN] = '\0'; >+ pdata->supplies[0].supply = supply_name; >+ } >+ } > } > > if (pdata->num_supplies < 1) { > >base-commit: 451e85e29c9d6f20639d4cfcff4b9dea280178cc >-- >2.41.0 >