Received: by 2002:a05:7412:3784:b0:e2:908c:2ebd with SMTP id jk4csp2482832rdb; Wed, 4 Oct 2023 02:34:23 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHeEqhCWb94aELkbRvcKwDYkKo840xx6KEwLHBN24NurGnhyeKmGuK2u0VsDmELMALLVYYv X-Received: by 2002:a17:903:32cb:b0:1c3:2ee6:3811 with SMTP id i11-20020a17090332cb00b001c32ee63811mr2242428plr.8.1696412063632; Wed, 04 Oct 2023 02:34:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696412063; cv=none; d=google.com; s=arc-20160816; b=jJho4IMqghwOGK7jG1eFMwq+qd6JB2a987PT15vtbyzCsv/IjisnuwDcV1KuPJN4rK 57EVAta4o6E3Zr+AqcILvPt1ujybeetbrr69JVtfx5jePaavGBuSDNKJ3Os8m3QGw8gn I5aZ7UHY+K5miulO8b36v6QMgFXNuXxGcm8vQh9gGbWubsCBTq6AyysyIVLiMu8Fj7gT Q65QQ/albRdY1EZ4R2qllCBtiF6NdYa9sv33ab8QVNOZHSC6A/k5T827DzO1a9vEirMm rNBA5177r8+xGYux9afK+qOJIo6LR5bvvXQQY5qCX9GaVrKm5BTDuh+AMXXJB/SBUiX1 OYCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=nT8ftubfCGwwT4A/BlmuxmyIj2PQDGT0AjFeJGDQBzI=; fh=+zipharILHv5cVdqkukO9ofsRJ80Py95CXEn7MDjnaU=; b=09Z5wW4faBqIyhy0u1hSzdGabwmdFxvCqST5zzUfyrJcITLuQXgflGF1NDio407YyJ gushjJMgdXWL87M2yuY5YOZPsp3Z4fsrzogb63oDZGDwVcQrWPB/jEpmskn1agbXlZIS 9Q0tlyx8scXst3URzvy15V8ACba+WYKYxGU3EF+xS0X8Voez2NkAbZgmA0NJtfF8qxp+ 240aRucotUIpwwZI2A9mLJyBRzzpJvLz/6K3dkdqxZL+jLTEw7Pj9EsU7HsqrZ5SPH2F 4+kBKW+WzoBQBCWhCVM3En1ko0SXSTkCqjqmPaZ1G4nVBjaw0IhpVQz7oUrZQH9FPq3m gQLA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@9elements.com header.s=google header.b=GzLb27r4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=9elements.com Return-Path: Received: from pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id t7-20020a1709027fc700b001bdf71d52b0si3350373plb.456.2023.10.04.02.34.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Oct 2023 02:34:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; dkim=pass header.i=@9elements.com header.s=google header.b=GzLb27r4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=9elements.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 70B0581A7D00; Wed, 4 Oct 2023 02:34:20 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241955AbjJDJeL (ORCPT + 99 others); Wed, 4 Oct 2023 05:34:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42014 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242007AbjJDJeK (ORCPT ); Wed, 4 Oct 2023 05:34:10 -0400 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9DF2DC4 for ; Wed, 4 Oct 2023 02:34:03 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-27927d37ec7so1385545a91.0 for ; Wed, 04 Oct 2023 02:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=9elements.com; s=google; t=1696412043; x=1697016843; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nT8ftubfCGwwT4A/BlmuxmyIj2PQDGT0AjFeJGDQBzI=; b=GzLb27r4FMpIdsdkt3iDk5mlJttIEKNGXBKrt6sJPpeno8PS1v0FD6cNSB4yVY6J5J Z70ZTcnSL0tz0kym0yj1r+qF9jFgACsTv6hgVJuOaRabDcdfkeMYRs7ACNsNn39wmGnr 18Wp+EKZO8rk1NXBbsOCirNbMsmp0lCO1Gt0TYejwh/QzhN0yNQV1VFh8SClNu18bPaZ Jc4hFmPg6k3fS22vpFKWJHdjjTmGa88qb0zuk2U3B/oRIE0Tks51HazxSvKV6ZhWML5P IP4W14UDJ1pUx5YDF2p64DzPSAQ2fn3zUGxR5QFmBRZUryr/QzE/59fZ00ZJbRPVbr+E /UiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696412043; x=1697016843; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nT8ftubfCGwwT4A/BlmuxmyIj2PQDGT0AjFeJGDQBzI=; b=mJYPbOqMTGwIRexK8iJzZQENOPKNJ2Nhf7I2Q+1dIHrWpcdRdmFC8lxwdtu+I4VmaU aAMk7HUGcG4MDs4biJutfHm3Nfd099LSg13fhRUXnDFcK6N75Lkh86wWUZEi5QwR02hx iiE6nRr/f5RkiKuw0c2ZyNku16aT8D8mvaNktUJqY0KzmoVW/RJtWhIws6Ez+1zouXiq PigIrfIR/o0RIVCInSftVN3pXfWWUIE38quqw4GFsihCqtRWbOi/1cs+Rx+6Eko0gGc+ oJxEVahGU5vY3sETWWtXFBoGWNA9UXzBXdMLBYwrOklDwhscQ/9n6gbyW6Dk985bQwfw NZoA== X-Gm-Message-State: AOJu0YyD5/BBdfh8Hh5WfNL+4RoTYbG/DrVs1kh9DBBD6jDE3NtAXOgv Lkbpfq9E88JI3mHDkWBrJSW8ZsB2u2tKwjojngoQew9iM2yT3UTI/3w= X-Received: by 2002:a17:90b:4a86:b0:274:5880:1606 with SMTP id lp6-20020a17090b4a8600b0027458801606mr1404817pjb.48.1696412043055; Wed, 04 Oct 2023 02:34:03 -0700 (PDT) MIME-Version: 1.0 References: <20230922090330.1570350-1-naresh.solanki@9elements.com> <53bf617a-0a47-4c51-9738-6f6e6e520d99@hatter.bewilderbeest.net> <6da614bf-c35c-4bae-84d9-fb9641dcbe59@hatter.bewilderbeest.net> In-Reply-To: <6da614bf-c35c-4bae-84d9-fb9641dcbe59@hatter.bewilderbeest.net> From: Naresh Solanki Date: Wed, 4 Oct 2023 15:03:52 +0530 Message-ID: Subject: Re: [RESEND PATCH] regulator: userspace-consumer: Retrieve supplies from DT To: Zev Weiss Cc: broonie@kernel.org, Liam Girdwood , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.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 (pete.vger.email [0.0.0.0]); Wed, 04 Oct 2023 02:34:20 -0700 (PDT) Hi On Sat, 23 Sept 2023 at 17:46, Zev Weiss wrote: > > On Sat, Sep 23, 2023 at 05:02:59AM PDT, Zev Weiss wrote: > >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 > > Or rather prop_supply_name_len(), to make the name a bit more accurate. > > >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'; > > Also, kstrndup() would be a cleaner replacement for these lines, though > then the cleanup would get messy, and sadly a devm_kstrndup() doesn't > currently exist -- maybe it'd be worth adding separately? Or > alternately you could just use devm_kstrdup() and then truncate it by > inserting a '\0'. Sure. Will make it like: char *supply_name = devm_kstrdup(&pdev->dev, prop_name, GFP_KERNEL); supply_name[supply_len] = '\0'; pdata->supplies[0].supply = supply_name; Regards, Naresh > > >>+ pdata->supplies[0].supply = supply_name; > >>+ } > >>+ } > >> } > >> > >> if (pdata->num_supplies < 1) { > >> > >>base-commit: 451e85e29c9d6f20639d4cfcff4b9dea280178cc > >>-- > >>2.41.0 > >>