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(®ulator_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, ®spec);
+ 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 ?
next prev parent 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).