linux-kernel - Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 11 May 2022 10:02:58 +0200
From:   LABBE Corentin <clabbe@...libre.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Andrew Lunn <andrew@...n.ch>, alexandre.torgue@...s.st.com,
        calvin.johnson@....nxp.com, davem@...emloft.net,
        edumazet@...gle.com, hkallweit1@...il.com,
        jernej.skrabec@...il.com, joabreu@...opsys.com,
        krzysztof.kozlowski+dt@...aro.org, kuba@...nel.org,
        lgirdwood@...il.com, linux@...linux.org.uk, pabeni@...hat.com,
        peppe.cavallaro@...com, robh+dt@...nel.org, samuel@...lland.org,
        wens@...e.org, netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-sunxi@...ts.linux.dev
Subject: Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply

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 ?