linux-kernel - Re: [RFC PATCH] mfd: arizona: Update device tree regulator bindings

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:	Thu, 26 Sep 2013 16:29:41 +0100
From:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	devicetree@...r.kernel.org, patches@...nsource.wolfsonmicro.com,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] mfd: arizona: Update device tree regulator bindings

Mark,

What are your thoughts on this approach? I basically add a way to
specify in the DAPM regulator supply widget that the supply lives
on the parent rather than the current device. If you like it I
will send it in as a proper patch.

I had considered adding something like a recursive regulator get
that works it's way up the tree but this felt rather invasive and
most places the user code does the regulator get rather than a
framework so the issue is only really likely to crop up with
regards to ASoC.

Thanks,
Charles
---
 include/sound/soc-dapm.h  |    2 ++
 sound/soc/codecs/wm5102.c |   13 +++++++------
 sound/soc/soc-dapm.c      |    7 ++++++-
 3 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index 27a72d5..f21b261 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -360,6 +360,8 @@ struct device;
 
 /* regulator widget flags */
 #define SND_SOC_DAPM_REGULATOR_BYPASS     0x1     /* bypass when disabled */
+/* use codec parent device for regulator get */
+#define SND_SOC_DAPM_REGULATOR_USE_PARENT 0x2
 
 struct snd_soc_dapm_widget;
 enum snd_soc_dapm_type;
diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c
index 8bbddc1..ee31f15 100644
--- a/sound/soc/codecs/wm5102.c
+++ b/sound/soc/codecs/wm5102.c
@@ -980,12 +980,13 @@ SND_SOC_DAPM_SUPPLY("OPCLK", ARIZONA_OUTPUT_SYSTEM_CLOCK,
 SND_SOC_DAPM_SUPPLY("ASYNCOPCLK", ARIZONA_OUTPUT_ASYNC_CLOCK,
 		    ARIZONA_OPCLK_ASYNC_ENA_SHIFT, 0, NULL, 0),
 
-SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD2", 0, 0),
-SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD3", 0, 0),
-SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20, 0),
-SND_SOC_DAPM_REGULATOR_SUPPLY("MICVDD", 0, SND_SOC_DAPM_REGULATOR_BYPASS),
-SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDL", 0, 0),
-SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDR", 0, 0),
+SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD2", 0, SND_SOC_DAPM_REGULATOR_USE_PARENT),
+SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD3", 0, SND_SOC_DAPM_REGULATOR_USE_PARENT),
+SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20, SND_SOC_DAPM_REGULATOR_USE_PARENT),
+SND_SOC_DAPM_REGULATOR_SUPPLY("MICVDD", 0, SND_SOC_DAPM_REGULATOR_BYPASS |
+					   SND_SOC_DAPM_REGULATOR_USE_PARENT),
+SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDL", 0, SND_SOC_DAPM_REGULATOR_USE_PARENT),
+SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDR", 0, SND_SOC_DAPM_REGULATOR_USE_PARENT),
 
 SND_SOC_DAPM_SIGGEN("TONE"),
 SND_SOC_DAPM_SIGGEN("NOISE"),
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index c17c14c..899bd2e 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -3181,7 +3181,12 @@ snd_soc_dapm_new_control(struct snd_soc_dapm_context *dapm,
 
 	switch (w->id) {
 	case snd_soc_dapm_regulator_supply:
-		w->regulator = devm_regulator_get(dapm->dev, w->name);
+		if (w->on_val & SND_SOC_DAPM_REGULATOR_USE_PARENT)
+			w->regulator = devm_regulator_get(dapm->dev->parent,
+							  w->name);
+		else
+			w->regulator = devm_regulator_get(dapm->dev, w->name);
+
 		if (IS_ERR(w->regulator)) {
 			ret = PTR_ERR(w->regulator);
 			dev_err(dapm->dev, "ASoC: Failed to request %s: %d\n",
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/