Message ID | 20230418145051.4192963-2-Naresh.Solanki@9elements.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2922462vqo; Tue, 18 Apr 2023 08:07:10 -0700 (PDT) X-Google-Smtp-Source: AKy350YD79zquc0N4LFcvP6X7HrmxtVTnXjpffoBK7aSsTVloqmgbn1rF17AWwOXE5ovORdt7qOY X-Received: by 2002:a05:6a00:189e:b0:625:e051:e462 with SMTP id x30-20020a056a00189e00b00625e051e462mr96721pfh.15.1681830429755; Tue, 18 Apr 2023 08:07:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681830429; cv=none; d=google.com; s=arc-20160816; b=YgMJUXHLoni8s2yrHvZ5f6oW9uuatGqZ7eC2iJrYQGnxPlN6dDi2j4VvpoIV+5SVHR UBiIl+lnZkZZ6X3LrE5tZUtMjYs/oL8YMN5rtfUOA/YnSd8nytn6Q0QVvsgq9C1hrhaC 9ItMHXX0q5ATgZr7DeY59BgsSCjxR67fd3zThy93GK7AlCGo+pp7DwyNqQyQJtFY+LgV ZzSaPWU/C5+dYrtA7NU3et29p09Y3UVd0jY307Rqv6w41gIgFJSs7UnvG9enh9CG672s KGu+4uC2zZA9XXTqKaZY7ABDfGh1hdm2ZsC6OoepGPCCMXSCk36U1dKbv9DxHnd4Hcb+ A6ZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=wJV57xSs2dDfAf5r16zc+/+R5eeJIggrJnMj0a1LSiU=; b=A4SaP659Uosi2fVwH/3VjobBTUGaoOPVbtWIvVXyimGMlPeYLVj7thq9lPiUOhTNkp KV7TeSce3407gOhk0IBx9GqtEGI1Jug9Ahb8zJiMkn4KS9YZzIksR1wWWBSrCNoWi4Vx gyyyGib2e3zVjv7zRLfP8aKI2XBW752CNHW5eC7tSDeoEXn2iBNNHq1uPXn5830g8/6p wPVh4Y4TwLGNnHYo4PX/wYhxMUjDPupr/Y/VwIQf0o47jpqtDqyC93r8ScctyQ+eZ06+ GI9kRtQ8BXbZjiIqVCJ4On3wBeRRNFclH6/97NjHKbuqx5jv6n0+J8dGxwmdNt9ag9Gl HBNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@9elements.com header.s=google header.b=VRMABw4R; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r26-20020aa7963a000000b0063b858960fasi7702258pfg.127.2023.04.18.08.06.43; Tue, 18 Apr 2023 08:07:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@9elements.com header.s=google header.b=VRMABw4R; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=9elements.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231623AbjDROvO (ORCPT <rfc822;leviz.kernel.dev@gmail.com> + 99 others); Tue, 18 Apr 2023 10:51:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231545AbjDROvA (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 18 Apr 2023 10:51:00 -0400 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B73D125B7 for <linux-kernel@vger.kernel.org>; Tue, 18 Apr 2023 07:50:59 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-3f16b99b990so22882575e9.0 for <linux-kernel@vger.kernel.org>; Tue, 18 Apr 2023 07:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=9elements.com; s=google; t=1681829458; x=1684421458; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=wJV57xSs2dDfAf5r16zc+/+R5eeJIggrJnMj0a1LSiU=; b=VRMABw4RSJhyc76sJKWgp2LNpymhYyaL3jGqm1PDs57nvREiTvC+3OqClQzCqdF/4s tr4sCS4x/0frof4DQ1xoKUQyBkDnUcPjaFuC38ChxbeF1RPFhPnv4hHy7em9b8sDXjM2 /fauE8QYdVPuU5KbZ+sBYIKaYEBpyqapOpEY83vjYsPFwJUutBQARt+JgUCwUxado0mQ uusl/sVS6CiUouItaRVZzImRu3TEwM0TJnR12I0u9qu27EhzWQmV/OzzUvYTNDZdiAG+ jF5UiImVXbZFtvrGRfyHpTcX5mU4fvi2NNlhvKpvg/G2atKjK48OVYy8UTaG8pfNY6UE jjlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681829458; x=1684421458; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wJV57xSs2dDfAf5r16zc+/+R5eeJIggrJnMj0a1LSiU=; b=TWxYJWGX7+O6ifBQcXXfPloNHs/ToruW+BN0YM5UWVDIiZEEe4PqzqxhgnN6lE+GB4 rXFdDBY+eyoZZPO6M/VDFaO98IwT/B+GeUZVrZ82MYSSuMe0LnQffizCe1uOXys7fUWF rTlKD+q7By27zFUYDz1sf1vbfBNAL+UZI9wYU6nw91Ctu+e2NZ8EDiyHL6TWI4FFj9zD IcJuzia+KQ/kfPAoq9IF50L9NqjRFRmjdrGy1q85mmUKBmcjk8v6TquFL8TeaRnslMZ/ szgBnV7s4C39AAWPvor/wdzjnrFMCrHl6NyMxPHIZzq6D07eghtQ+WUj6SlOUXJQdJWv kayA== X-Gm-Message-State: AAQBX9c2IxZKvfOGLLSeMjPgZ1+mLHwTxU6ikXSy8swauNmMozI9fUyh qhj962qo7s2HMo/0MtmFSmHXgCpIYopbaV1hlWE5OA== X-Received: by 2002:a5d:690f:0:b0:2f9:a822:89bf with SMTP id t15-20020a5d690f000000b002f9a82289bfmr2222232wru.16.1681829457870; Tue, 18 Apr 2023 07:50:57 -0700 (PDT) Received: from stroh80.sec.9e.network (ip-078-094-000-051.um19.pools.vodafone-ip.de. [78.94.0.51]) by smtp.gmail.com with ESMTPSA id z16-20020adff750000000b002fb6a79dea0sm3787823wrp.7.2023.04.18.07.50.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Apr 2023 07:50:57 -0700 (PDT) From: Naresh Solanki <naresh.solanki@9elements.com> X-Google-Original-From: Naresh Solanki <Naresh.Solanki@9elements.com> To: Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org> Cc: Naresh Solanki <Naresh.Solanki@9elements.com>, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] regulator: userspace-consumer: Multiple regulators Date: Tue, 18 Apr 2023 16:50:51 +0200 Message-Id: <20230418145051.4192963-2-Naresh.Solanki@9elements.com> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230418145051.4192963-1-Naresh.Solanki@9elements.com> References: <20230418145051.4192963-1-Naresh.Solanki@9elements.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763527024652079418?= X-GMAIL-MSGID: =?utf-8?q?1763527024652079418?= |
Series |
[1/2] dt-bindings: regulator: Add dt property
|
|
Commit Message
Naresh Solanki
April 18, 2023, 2:50 p.m. UTC
Use property regulator-supplies to determine all regulator
supplies.
This is useful in case of a connector having 2 or more supplies.
Example: PCIe connector on mainboard can be powered by 12V & 3.3V
suplies.
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
---
drivers/regulator/userspace-consumer.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
Comments
On Tue, Apr 18, 2023 at 07:50:51AM PDT, Naresh Solanki wrote: >Use property regulator-supplies to determine all regulator >supplies. >This is useful in case of a connector having 2 or more supplies. >Example: PCIe connector on mainboard can be powered by 12V & 3.3V >suplies. > >Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com> >--- > drivers/regulator/userspace-consumer.c | 19 +++++++++++++++---- > 1 file changed, 15 insertions(+), 4 deletions(-) > >diff --git a/drivers/regulator/userspace-consumer.c b/drivers/regulator/userspace-consumer.c >index 97f075ed68c9..0bb49547b926 100644 >--- a/drivers/regulator/userspace-consumer.c >+++ b/drivers/regulator/userspace-consumer.c >@@ -120,7 +120,10 @@ 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; >- int ret; >+ struct device_node *np = pdev->dev.of_node; >+ struct property *prop; >+ const char *supply; >+ int ret, count = 0; > > pdata = dev_get_platdata(&pdev->dev); > if (!pdata) { >@@ -131,11 +134,19 @@ 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 = of_property_count_strings(np, "regulator-supplies"); >+ if (pdata->num_supplies < 0) { >+ dev_err(&pdev->dev, "could not parse property regulator-supplies"); >+ return -EINVAL; >+ } >+ pdata->supplies = devm_kzalloc(&pdev->dev, >+ sizeof(*pdata->supplies) * pdata->num_supplies, >+ GFP_KERNEL); AFAICT this doesn't appear to implement the "vout" default specified in the dt-binding patch? Also, since the core of the userspace-consumer driver itself already supports multiple regulators, it might be nice for the subject line to mention DT supplies or something a bit more specifically. > if (!pdata->supplies) > return -ENOMEM; >- pdata->supplies[0].supply = "vout"; >+ >+ of_property_for_each_string(np, "regulator-supplies", prop, supply) >+ pdata->supplies[count++].supply = supply; > } > > if (pdata->num_supplies < 1) { >-- >2.39.1 > >
Hi Zev, On 20-04-2023 05:32 am, Zev Weiss wrote: > On Tue, Apr 18, 2023 at 07:50:51AM PDT, Naresh Solanki wrote: >> Use property regulator-supplies to determine all regulator >> supplies. >> This is useful in case of a connector having 2 or more supplies. >> Example: PCIe connector on mainboard can be powered by 12V & 3.3V >> suplies. >> >> Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com> >> --- >> drivers/regulator/userspace-consumer.c | 19 +++++++++++++++---- >> 1 file changed, 15 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/regulator/userspace-consumer.c >> b/drivers/regulator/userspace-consumer.c >> index 97f075ed68c9..0bb49547b926 100644 >> --- a/drivers/regulator/userspace-consumer.c >> +++ b/drivers/regulator/userspace-consumer.c >> @@ -120,7 +120,10 @@ 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; >> - int ret; >> + struct device_node *np = pdev->dev.of_node; >> + struct property *prop; >> + const char *supply; >> + int ret, count = 0; >> >> pdata = dev_get_platdata(&pdev->dev); >> if (!pdata) { >> @@ -131,11 +134,19 @@ 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 = of_property_count_strings(np, >> "regulator-supplies"); >> + if (pdata->num_supplies < 0) { >> + dev_err(&pdev->dev, "could not parse property >> regulator-supplies"); >> + return -EINVAL; >> + } >> + pdata->supplies = devm_kzalloc(&pdev->dev, >> + sizeof(*pdata->supplies) * >> pdata->num_supplies, >> + GFP_KERNEL); > > AFAICT this doesn't appear to implement the "vout" default specified in > the dt-binding patch? The "regulator-supplies" property will hold the default value of "vout" unless specified otherwise. As a result, the string enumeration retrieves the value of "vout" by default, and the "vout-supply" property is utilized for the regulator. > > Also, since the core of the userspace-consumer driver itself already > supports multiple regulators, it might be nice for the subject line to > mention DT supplies or something a bit more specifically. Sure. How about 'Support multiple supplies' ? > >> if (!pdata->supplies) >> return -ENOMEM; >> - pdata->supplies[0].supply = "vout"; >> + >> + of_property_for_each_string(np, "regulator-supplies", prop, >> supply) >> + pdata->supplies[count++].supply = supply; >> } >> >> if (pdata->num_supplies < 1) { >> -- >> 2.39.1 >> >> Regards, Naresh
On Thu, Apr 20, 2023 at 01:46:14AM PDT, Naresh Solanki wrote: >Hi Zev, > >On 20-04-2023 05:32 am, Zev Weiss wrote: >>On Tue, Apr 18, 2023 at 07:50:51AM PDT, Naresh Solanki wrote: >>>Use property regulator-supplies to determine all regulator >>>supplies. >>>This is useful in case of a connector having 2 or more supplies. >>>Example: PCIe connector on mainboard can be powered by 12V & 3.3V >>>suplies. >>> >>>Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com> >>>--- >>>drivers/regulator/userspace-consumer.c | 19 +++++++++++++++---- >>>1 file changed, 15 insertions(+), 4 deletions(-) >>> >>>diff --git a/drivers/regulator/userspace-consumer.c >>>b/drivers/regulator/userspace-consumer.c >>>index 97f075ed68c9..0bb49547b926 100644 >>>--- a/drivers/regulator/userspace-consumer.c >>>+++ b/drivers/regulator/userspace-consumer.c >>>@@ -120,7 +120,10 @@ 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; >>>- int ret; >>>+ struct device_node *np = pdev->dev.of_node; >>>+ struct property *prop; >>>+ const char *supply; >>>+ int ret, count = 0; >>> >>> pdata = dev_get_platdata(&pdev->dev); >>> if (!pdata) { >>>@@ -131,11 +134,19 @@ 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 = of_property_count_strings(np, >>>"regulator-supplies"); >>>+ if (pdata->num_supplies < 0) { >>>+ dev_err(&pdev->dev, "could not parse property >>>regulator-supplies"); >>>+ return -EINVAL; >>>+ } >>>+ pdata->supplies = devm_kzalloc(&pdev->dev, >>>+ sizeof(*pdata->supplies) * >>>pdata->num_supplies, >>>+ GFP_KERNEL); >> >>AFAICT this doesn't appear to implement the "vout" default specified >>in the dt-binding patch? >The "regulator-supplies" property will hold the default value of >"vout" unless specified otherwise. As a result, the string enumeration >retrieves the value of "vout" by default, and the "vout-supply" >property is utilized for the regulator. > With the disclaimer that I'm not a DT expert, that's not my understanding of how DT works. I don't think the 'default' value specified in the binding forces the fdt to always include that value if it's not present in the dts (since I'm pretty sure dtc doesn't even look at the binding to know that a default exists when compiling the dts); rather, it's information meant to be used by the software implementing support for that device (e.g. a driver for it) about what value to assume if the property isn't present in the fdt. >> >>Also, since the core of the userspace-consumer driver itself already >>supports multiple regulators, it might be nice for the subject line >>to mention DT supplies or something a bit more specifically. >Sure. How about 'Support multiple supplies' ? I meant that it should explicitly mention "DT" (or perhaps "OF"). The driver's structure has supported multiple supplies since it was first introduced in 2009, so "Support multiple supplies" sounds like this commit is adding functionality that was already there. What this patch is doing is connecting that existing support to the OF support logic so that it can be used in a device-tree context. >> >>> if (!pdata->supplies) >>> return -ENOMEM; >>>- pdata->supplies[0].supply = "vout"; >>>+ >>>+ of_property_for_each_string(np, "regulator-supplies", >>>prop, supply) >>>+ pdata->supplies[count++].supply = supply; >>> } >>> >>> if (pdata->num_supplies < 1) { >>>-- >>>2.39.1 >>> >>> >Regards, >Naresh
Hi Zev, On 20-04-2023 04:27 pm, Zev Weiss wrote: > On Thu, Apr 20, 2023 at 01:46:14AM PDT, Naresh Solanki wrote: >> Hi Zev, >> >> On 20-04-2023 05:32 am, Zev Weiss wrote: >>> On Tue, Apr 18, 2023 at 07:50:51AM PDT, Naresh Solanki wrote: >>>> Use property regulator-supplies to determine all regulator >>>> supplies. >>>> This is useful in case of a connector having 2 or more supplies. >>>> Example: PCIe connector on mainboard can be powered by 12V & 3.3V >>>> suplies. >>>> >>>> Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com> >>>> --- >>>> drivers/regulator/userspace-consumer.c | 19 +++++++++++++++---- >>>> 1 file changed, 15 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/drivers/regulator/userspace-consumer.c >>>> b/drivers/regulator/userspace-consumer.c >>>> index 97f075ed68c9..0bb49547b926 100644 >>>> --- a/drivers/regulator/userspace-consumer.c >>>> +++ b/drivers/regulator/userspace-consumer.c >>>> @@ -120,7 +120,10 @@ 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; >>>> - int ret; >>>> + struct device_node *np = pdev->dev.of_node; >>>> + struct property *prop; >>>> + const char *supply; >>>> + int ret, count = 0; >>>> >>>> pdata = dev_get_platdata(&pdev->dev); >>>> if (!pdata) { >>>> @@ -131,11 +134,19 @@ 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 = of_property_count_strings(np, >>>> "regulator-supplies"); >>>> + if (pdata->num_supplies < 0) { >>>> + dev_err(&pdev->dev, "could not parse property >>>> regulator-supplies"); >>>> + return -EINVAL; >>>> + } >>>> + pdata->supplies = devm_kzalloc(&pdev->dev, >>>> + sizeof(*pdata->supplies) * >>>> pdata->num_supplies, >>>> + GFP_KERNEL); >>> >>> AFAICT this doesn't appear to implement the "vout" default specified >>> in the dt-binding patch? >> The "regulator-supplies" property will hold the default value of >> "vout" unless specified otherwise. As a result, the string enumeration >> retrieves the value of "vout" by default, and the "vout-supply" >> property is utilized for the regulator. >> > > With the disclaimer that I'm not a DT expert, that's not my > understanding of how DT works. I don't think the 'default' value > specified in the binding forces the fdt to always include that value if > it's not present in the dts (since I'm pretty sure dtc doesn't even look > at the binding to know that a default exists when compiling the dts); > rather, it's information meant to be used by the software implementing > support for that device (e.g. a driver for it) about what value to > assume if the property isn't present in the fdt. I apologize for the oversight on my part. Upon further testing, I have discovered that the default did not reflect in the debug prints. I will address this issue and include the proper fix in the next patchset. Thank you for bringing this to my attention > >>> >>> Also, since the core of the userspace-consumer driver itself already >>> supports multiple regulators, it might be nice for the subject line >>> to mention DT supplies or something a bit more specifically. >> Sure. How about 'Support multiple supplies' ? > > I meant that it should explicitly mention "DT" (or perhaps "OF"). The > driver's structure has supported multiple supplies since it was first > introduced in 2009, so "Support multiple supplies" sounds like this > commit is adding functionality that was already there. What this patch > is doing is connecting that existing support to the OF support logic so > that it can be used in a device-tree context. Sure. Will make it something like "Support multiple supplies in DT". > >>> >>>> if (!pdata->supplies) >>>> return -ENOMEM; >>>> - pdata->supplies[0].supply = "vout"; >>>> + >>>> + of_property_for_each_string(np, "regulator-supplies", prop, >>>> supply) >>>> + pdata->supplies[count++].supply = supply; >>>> } >>>> >>>> if (pdata->num_supplies < 1) { >>>> -- >>>> 2.39.1 >>>> >>>> >> Regards, >> Naresh Regards, Naresh
diff --git a/drivers/regulator/userspace-consumer.c b/drivers/regulator/userspace-consumer.c index 97f075ed68c9..0bb49547b926 100644 --- a/drivers/regulator/userspace-consumer.c +++ b/drivers/regulator/userspace-consumer.c @@ -120,7 +120,10 @@ 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; - int ret; + struct device_node *np = pdev->dev.of_node; + struct property *prop; + const char *supply; + int ret, count = 0; pdata = dev_get_platdata(&pdev->dev); if (!pdata) { @@ -131,11 +134,19 @@ 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 = of_property_count_strings(np, "regulator-supplies"); + if (pdata->num_supplies < 0) { + dev_err(&pdev->dev, "could not parse property regulator-supplies"); + return -EINVAL; + } + pdata->supplies = devm_kzalloc(&pdev->dev, + sizeof(*pdata->supplies) * pdata->num_supplies, + GFP_KERNEL); if (!pdata->supplies) return -ENOMEM; - pdata->supplies[0].supply = "vout"; + + of_property_for_each_string(np, "regulator-supplies", prop, supply) + pdata->supplies[count++].supply = supply; } if (pdata->num_supplies < 1) {