devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: LABBE Corentin <clabbe@baylibre.com>
To: Mark Brown <broonie@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
	alexandre.torgue@foss.st.com, calvin.johnson@oss.nxp.com,
	davem@davemloft.net, edumazet@google.com, hkallweit1@gmail.com,
	jernej.skrabec@gmail.com, joabreu@synopsys.com,
	krzysztof.kozlowski+dt@linaro.org, kuba@kernel.org,
	lgirdwood@gmail.com, linux@armlinux.org.uk, pabeni@redhat.com,
	peppe.cavallaro@st.com, robh+dt@kernel.org, samuel@sholland.org,
	wens@csie.org, netdev@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply
Date: Wed, 11 May 2022 10:02:58 +0200	[thread overview]
Message-ID: <YnttssHyCf8PJJev@Red> (raw)
In-Reply-To: <YnlHwpiow9Flgzas@sirena.org.uk>

Le Mon, May 09, 2022 at 05:56:34PM +0100, Mark Brown a écrit :
> On Mon, May 09, 2022 at 06:38:05PM +0200, Andrew Lunn wrote:
> 
> > So we have a collection of regulators, varying in numbers between
> > different PHYs, with different vendor names and purposes. In general,
> > they all should be turned on. Yet we want them named so it is clear
> > what is going on.
> 
> > Is there a generic solution here so that the phylib core can somehow
> > enumerate them and turn them on, without actually knowing what they
> > are called because they have vendor specific names in order to be
> > clear what they are?
> 
> > There must be a solution to this, phylib cannot be the first subsystem
> > to have this requirement, so if you could point to an example, that
> > would be great.
> 
> No, it's not really come up much before - generally things with
> regulator control that have generic drivers tend not to be sophisticated
> enough to have more than one supply, or to be on an enumerable bus where
> the power is part of the bus specification so have the power specified
> as part of the bus.  You'd need to extend the regulator bindings to
> support parallel array of phandles and array of names properties like
> clocks have as an option like you were asking for, which would doubtless
> be fun for validation but is probably the thing here.

Does you mean something like this:
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 1e54a833f2cf..404f5b874b59 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -351,6 +351,32 @@ static void regulator_lock_dependent(struct regulator_dev *rdev,
 	mutex_unlock(&regulator_list_mutex);
 }
 
+/**
+ * of_get_regulator_from_list - get a regulator device node based on supply name
+ * from a DT regulators list
+ * @dev: Device pointer for the consumer (of regulator) device
+ * @supply: regulator supply name
+ *
+ * Extract the regulator device node corresponding to the supply name.
+ * returns the device node corresponding to the regulator if found, else
+ * returns NULL.
+ */
+static struct device_node *of_get_regulator_from_list(struct device *dev,
+						      struct device_node *np,
+						      const char *supply)
+{
+	int index, ret;
+	struct of_phandle_args regspec;
+
+	index = of_property_match_string(np, "regulator-names", supply);
+	if (index >= 0) {
+		ret = of_parse_phandle_with_args(np, "regulators", NULL, index, &regspec);
+		if (ret == 0)
+			return regspec.np;
+	}
+	return NULL;
+}
+
 /**
  * of_get_child_regulator - get a child regulator device node
  * based on supply name
@@ -362,17 +388,23 @@ static void regulator_lock_dependent(struct regulator_dev *rdev,
  * returns the device node corresponding to the regulator if found, else
  * returns NULL.
  */
-static struct device_node *of_get_child_regulator(struct device_node *parent,
-						  const char *prop_name)
+static struct device_node *of_get_child_regulator(struct device *dev,
+						  struct device_node *parent,
+						  const char *supply)
 {
 	struct device_node *regnode = NULL;
 	struct device_node *child = NULL;
+	char prop_name[64]; /* 64 is max size of property name */
 
+	snprintf(prop_name, 64, "%s-supply", supply);
 	for_each_child_of_node(parent, child) {
+		regnode = of_get_regulator_from_list(dev, child, supply);
+		if (regnode)
+			return regnode;
 		regnode = of_parse_phandle(child, prop_name, 0);
 
 		if (!regnode) {
-			regnode = of_get_child_regulator(child, prop_name);
+			regnode = of_get_child_regulator(dev, child, prop_name);
 			if (regnode)
 				goto err_node_put;
 		} else {
@@ -401,12 +433,15 @@ static struct device_node *of_get_regulator(struct device *dev, const char *supp
 	char prop_name[64]; /* 64 is max size of property name */
 
 	dev_dbg(dev, "Looking up %s-supply from device tree\n", supply);
+	regnode = of_get_regulator_from_list(dev, dev->of_node, supply);
+	if (regnode)
+		return regnode;
 
 	snprintf(prop_name, 64, "%s-supply", supply);
 	regnode = of_parse_phandle(dev->of_node, prop_name, 0);
 
 	if (!regnode) {
-		regnode = of_get_child_regulator(dev->of_node, prop_name);
+		regnode = of_get_child_regulator(dev, dev->of_node, supply);
 		if (regnode)
 			return regnode;
 

And then for our case, a regulator_get_bulk will be needed.
Does I well understood what you mean ?

  reply	other threads:[~2022-05-11  8:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-09  7:48 [PATCH 0/6] arm64: add ethernet to orange pi 3 Corentin Labbe
2022-05-09  7:48 ` [PATCH 1/6] phy: handle optional regulator for PHY Corentin Labbe
2022-05-09  7:48 ` [PATCH 2/6] net: stmmac: dwmac-sun8i: remove regulator Corentin Labbe
2022-05-09 14:09   ` Andre Przywara
2022-05-09 14:38     ` LABBE Corentin
2022-05-09  7:48 ` [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply Corentin Labbe
2022-05-09 12:17   ` Andrew Lunn
2022-05-09 13:26     ` LABBE Corentin
2022-05-09 16:02       ` Andrew Lunn
2022-05-09 16:12         ` Mark Brown
2022-05-09 16:38           ` Andrew Lunn
2022-05-09 16:56             ` Mark Brown
2022-05-11  8:02               ` LABBE Corentin [this message]
2022-05-11 12:50                 ` Mark Brown
2022-05-17  0:47             ` Rob Herring
2022-05-09  7:48 ` [PATCH 4/6] ARM: dts: sunxi: move phy regulator in PHY node Corentin Labbe
2022-05-09 10:55   ` Andre Przywara
2022-05-09 11:16     ` LABBE Corentin
2022-05-09  7:48 ` [PATCH 5/6] arm64: dts: allwinner: " Corentin Labbe
2022-05-09  7:48 ` [PATCH 6/6] arm64: dts: allwinner: orange-pi-3: Enable ethernet Corentin Labbe
2022-05-09 12:20 ` [PATCH 0/6] arm64: add ethernet to orange pi 3 Andrew Lunn
2022-05-09 13:27   ` LABBE Corentin
2022-05-09 15:19     ` Andrew Lunn
2022-05-09 15:24       ` LABBE Corentin
2022-05-09 15:56         ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YnttssHyCf8PJJev@Red \
    --to=clabbe@baylibre.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew@lunn.ch \
    --cc=broonie@kernel.org \
    --cc=calvin.johnson@oss.nxp.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=joabreu@synopsys.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=peppe.cavallaro@st.com \
    --cc=robh+dt@kernel.org \
    --cc=samuel@sholland.org \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).