All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 2/2] regulator: palmas: add input supply names
@ 2013-03-18  9:29 ` Laxman Dewangan
  0 siblings, 0 replies; 14+ messages in thread
From: Laxman Dewangan @ 2013-03-18  9:29 UTC (permalink / raw)
  To: broonie; +Cc: linux-kernel, swarren, linux-tegra, lrg, Laxman Dewangan

Palmas regulator support the different input supply pins for each of
the rails. Fill the regulator info data with their input supply pin
names.

The pin supply names is passed to regulator_register() only when there
is valid regulator_init_data. If regulator_init_data is not present
for the rail then it is assumed that given rail's input pin is left
unconnected.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
 drivers/regulator/palmas-regulator.c |   28 ++++++++++++++++++++++++++++
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
index 4a45942..119d83b 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -29,6 +29,7 @@
 
 struct regs_info {
 	char	*name;
+	char	*sname;
 	u8	vsel_addr;
 	u8	ctrl_addr;
 	u8	tstep_addr;
@@ -37,110 +38,131 @@ struct regs_info {
 static const struct regs_info palmas_regs_info[] = {
 	{
 		.name		= "SMPS12",
+		.sname		= "smps1-in",
 		.vsel_addr	= PALMAS_SMPS12_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS12_CTRL,
 		.tstep_addr	= PALMAS_SMPS12_TSTEP,
 	},
 	{
 		.name		= "SMPS123",
+		.sname		= "smps1-in",
 		.vsel_addr	= PALMAS_SMPS12_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS12_CTRL,
 		.tstep_addr	= PALMAS_SMPS12_TSTEP,
 	},
 	{
 		.name		= "SMPS3",
+		.sname		= "smps3-in",
 		.vsel_addr	= PALMAS_SMPS3_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS3_CTRL,
 	},
 	{
 		.name		= "SMPS45",
+		.sname		= "smps4-in",
 		.vsel_addr	= PALMAS_SMPS45_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS45_CTRL,
 		.tstep_addr	= PALMAS_SMPS45_TSTEP,
 	},
 	{
 		.name		= "SMPS457",
+		.sname		= "smps4-in",
 		.vsel_addr	= PALMAS_SMPS45_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS45_CTRL,
 		.tstep_addr	= PALMAS_SMPS45_TSTEP,
 	},
 	{
 		.name		= "SMPS6",
+		.sname		= "smps6-in",
 		.vsel_addr	= PALMAS_SMPS6_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS6_CTRL,
 		.tstep_addr	= PALMAS_SMPS6_TSTEP,
 	},
 	{
 		.name		= "SMPS7",
+		.sname		= "smps7-in",
 		.vsel_addr	= PALMAS_SMPS7_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS7_CTRL,
 	},
 	{
 		.name		= "SMPS8",
+		.sname		= "smps8-in",
 		.vsel_addr	= PALMAS_SMPS8_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS8_CTRL,
 		.tstep_addr	= PALMAS_SMPS8_TSTEP,
 	},
 	{
 		.name		= "SMPS9",
+		.sname		= "smps9-in",
 		.vsel_addr	= PALMAS_SMPS9_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS9_CTRL,
 	},
 	{
 		.name		= "SMPS10",
+		.sname		= "smps10-in",
 	},
 	{
 		.name		= "LDO1",
+		.sname		= "ldo1-in",
 		.vsel_addr	= PALMAS_LDO1_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO1_CTRL,
 	},
 	{
 		.name		= "LDO2",
+		.sname		= "ldo2-in",
 		.vsel_addr	= PALMAS_LDO2_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO2_CTRL,
 	},
 	{
 		.name		= "LDO3",
+		.sname		= "ldo3-in",
 		.vsel_addr	= PALMAS_LDO3_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO3_CTRL,
 	},
 	{
 		.name		= "LDO4",
+		.sname		= "ldo4-in",
 		.vsel_addr	= PALMAS_LDO4_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO4_CTRL,
 	},
 	{
 		.name		= "LDO5",
+		.sname		= "ldo5-in",
 		.vsel_addr	= PALMAS_LDO5_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO5_CTRL,
 	},
 	{
 		.name		= "LDO6",
+		.sname		= "ldo6-in",
 		.vsel_addr	= PALMAS_LDO6_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO6_CTRL,
 	},
 	{
 		.name		= "LDO7",
+		.sname		= "ldo7-in",
 		.vsel_addr	= PALMAS_LDO7_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO7_CTRL,
 	},
 	{
 		.name		= "LDO8",
+		.sname		= "ldo8-in",
 		.vsel_addr	= PALMAS_LDO8_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO8_CTRL,
 	},
 	{
 		.name		= "LDO9",
+		.sname		= "ldo9-in",
 		.vsel_addr	= PALMAS_LDO9_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO9_CTRL,
 	},
 	{
 		.name		= "LDOLN",
+		.sname		= "ldoln-in",
 		.vsel_addr	= PALMAS_LDOLN_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDOLN_CTRL,
 	},
 	{
 		.name		= "LDOUSB",
+		.sname		= "ldousb-in",
 		.vsel_addr	= PALMAS_LDOUSB_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDOUSB_CTRL,
 	},
@@ -710,6 +732,9 @@ static int palmas_regulators_probe(struct platform_device *pdev)
 		else
 			config.init_data = NULL;
 
+		if (config.init_data)
+			pmic->desc[id].supply_name = palmas_regs_info[id].sname;
+
 		config.of_node = palmas_matches[id].of_node;
 
 		rdev = regulator_register(&pmic->desc[id], &config);
@@ -756,6 +781,9 @@ static int palmas_regulators_probe(struct platform_device *pdev)
 		else
 			config.init_data = NULL;
 
+		if (config.init_data)
+			pmic->desc[id].supply_name = palmas_regs_info[id].sname;
+
 		config.of_node = palmas_matches[id].of_node;
 
 		rdev = regulator_register(&pmic->desc[id], &config);
-- 
1.7.1.1

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 2/2] regulator: palmas: add input supply names
@ 2013-03-18  9:29 ` Laxman Dewangan
  0 siblings, 0 replies; 14+ messages in thread
From: Laxman Dewangan @ 2013-03-18  9:29 UTC (permalink / raw)
  To: broonie; +Cc: linux-kernel, swarren, linux-tegra, lrg, Laxman Dewangan

Palmas regulator support the different input supply pins for each of
the rails. Fill the regulator info data with their input supply pin
names.

The pin supply names is passed to regulator_register() only when there
is valid regulator_init_data. If regulator_init_data is not present
for the rail then it is assumed that given rail's input pin is left
unconnected.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
 drivers/regulator/palmas-regulator.c |   28 ++++++++++++++++++++++++++++
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
index 4a45942..119d83b 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -29,6 +29,7 @@
 
 struct regs_info {
 	char	*name;
+	char	*sname;
 	u8	vsel_addr;
 	u8	ctrl_addr;
 	u8	tstep_addr;
@@ -37,110 +38,131 @@ struct regs_info {
 static const struct regs_info palmas_regs_info[] = {
 	{
 		.name		= "SMPS12",
+		.sname		= "smps1-in",
 		.vsel_addr	= PALMAS_SMPS12_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS12_CTRL,
 		.tstep_addr	= PALMAS_SMPS12_TSTEP,
 	},
 	{
 		.name		= "SMPS123",
+		.sname		= "smps1-in",
 		.vsel_addr	= PALMAS_SMPS12_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS12_CTRL,
 		.tstep_addr	= PALMAS_SMPS12_TSTEP,
 	},
 	{
 		.name		= "SMPS3",
+		.sname		= "smps3-in",
 		.vsel_addr	= PALMAS_SMPS3_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS3_CTRL,
 	},
 	{
 		.name		= "SMPS45",
+		.sname		= "smps4-in",
 		.vsel_addr	= PALMAS_SMPS45_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS45_CTRL,
 		.tstep_addr	= PALMAS_SMPS45_TSTEP,
 	},
 	{
 		.name		= "SMPS457",
+		.sname		= "smps4-in",
 		.vsel_addr	= PALMAS_SMPS45_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS45_CTRL,
 		.tstep_addr	= PALMAS_SMPS45_TSTEP,
 	},
 	{
 		.name		= "SMPS6",
+		.sname		= "smps6-in",
 		.vsel_addr	= PALMAS_SMPS6_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS6_CTRL,
 		.tstep_addr	= PALMAS_SMPS6_TSTEP,
 	},
 	{
 		.name		= "SMPS7",
+		.sname		= "smps7-in",
 		.vsel_addr	= PALMAS_SMPS7_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS7_CTRL,
 	},
 	{
 		.name		= "SMPS8",
+		.sname		= "smps8-in",
 		.vsel_addr	= PALMAS_SMPS8_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS8_CTRL,
 		.tstep_addr	= PALMAS_SMPS8_TSTEP,
 	},
 	{
 		.name		= "SMPS9",
+		.sname		= "smps9-in",
 		.vsel_addr	= PALMAS_SMPS9_VOLTAGE,
 		.ctrl_addr	= PALMAS_SMPS9_CTRL,
 	},
 	{
 		.name		= "SMPS10",
+		.sname		= "smps10-in",
 	},
 	{
 		.name		= "LDO1",
+		.sname		= "ldo1-in",
 		.vsel_addr	= PALMAS_LDO1_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO1_CTRL,
 	},
 	{
 		.name		= "LDO2",
+		.sname		= "ldo2-in",
 		.vsel_addr	= PALMAS_LDO2_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO2_CTRL,
 	},
 	{
 		.name		= "LDO3",
+		.sname		= "ldo3-in",
 		.vsel_addr	= PALMAS_LDO3_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO3_CTRL,
 	},
 	{
 		.name		= "LDO4",
+		.sname		= "ldo4-in",
 		.vsel_addr	= PALMAS_LDO4_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO4_CTRL,
 	},
 	{
 		.name		= "LDO5",
+		.sname		= "ldo5-in",
 		.vsel_addr	= PALMAS_LDO5_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO5_CTRL,
 	},
 	{
 		.name		= "LDO6",
+		.sname		= "ldo6-in",
 		.vsel_addr	= PALMAS_LDO6_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO6_CTRL,
 	},
 	{
 		.name		= "LDO7",
+		.sname		= "ldo7-in",
 		.vsel_addr	= PALMAS_LDO7_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO7_CTRL,
 	},
 	{
 		.name		= "LDO8",
+		.sname		= "ldo8-in",
 		.vsel_addr	= PALMAS_LDO8_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO8_CTRL,
 	},
 	{
 		.name		= "LDO9",
+		.sname		= "ldo9-in",
 		.vsel_addr	= PALMAS_LDO9_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDO9_CTRL,
 	},
 	{
 		.name		= "LDOLN",
+		.sname		= "ldoln-in",
 		.vsel_addr	= PALMAS_LDOLN_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDOLN_CTRL,
 	},
 	{
 		.name		= "LDOUSB",
+		.sname		= "ldousb-in",
 		.vsel_addr	= PALMAS_LDOUSB_VOLTAGE,
 		.ctrl_addr	= PALMAS_LDOUSB_CTRL,
 	},
@@ -710,6 +732,9 @@ static int palmas_regulators_probe(struct platform_device *pdev)
 		else
 			config.init_data = NULL;
 
+		if (config.init_data)
+			pmic->desc[id].supply_name = palmas_regs_info[id].sname;
+
 		config.of_node = palmas_matches[id].of_node;
 
 		rdev = regulator_register(&pmic->desc[id], &config);
@@ -756,6 +781,9 @@ static int palmas_regulators_probe(struct platform_device *pdev)
 		else
 			config.init_data = NULL;
 
+		if (config.init_data)
+			pmic->desc[id].supply_name = palmas_regs_info[id].sname;
+
 		config.of_node = palmas_matches[id].of_node;
 
 		rdev = regulator_register(&pmic->desc[id], &config);
-- 
1.7.1.1


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 1/2] regulator: palmas: rename probe/remove callback functions
  2013-03-18  9:29 ` Laxman Dewangan
@ 2013-03-18  9:29   ` Laxman Dewangan
  -1 siblings, 0 replies; 14+ messages in thread
From: Laxman Dewangan @ 2013-03-18  9:29 UTC (permalink / raw)
  To: broonie; +Cc: linux-kernel, swarren, linux-tegra, lrg, Laxman Dewangan

When palmas regulator probe creates stack dump during initialization
due to some crash, it prints the call trace as follows:
[3.166321] [<c028fa20>] (_regmap_read+0x5c/0xa8) from [<c028fab0>] (regmap_read+0x44/0x5c)
[3.174669] [<c028fab0>] (regmap_read+0x44/0x5c) from [<c023062c>] (palmas_probe+0x240/0x7d0)
[3.183193] [<c023062c>] (palmas_probe+0x240/0x7d0) from [<c0284064>] (platform_drv_probe+0x14/0x18)
[3.192322] [<c0284064>] (platform_drv_probe+0x14/0x18) from [<c0282ee4>] (driver_probe_device+0x104/0x214)
[3.202055] [<c0282ee4>] (driver_probe_device+0x104/0x214) from [<c028167c>] (bus_for_each_drv+0x5c/0x88)

The palmas_probe is current name but it helps on debugging if the
function name is more appropriate to the sub-module name.

Renaming the palmas_probe() to palmas_regulator_probe() and
palmas_remove() to palams_regulator_remove().

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
 drivers/regulator/palmas-regulator.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
index a9b558e..4a45942 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -582,7 +582,7 @@ static void palmas_dt_to_pdata(struct device *dev,
 }
 
 
-static int palmas_probe(struct platform_device *pdev)
+static int palmas_regulators_probe(struct platform_device *pdev)
 {
 	struct palmas *palmas = dev_get_drvdata(pdev->dev.parent);
 	struct palmas_pmic_platform_data *pdata = pdev->dev.platform_data;
@@ -791,7 +791,7 @@ err_unregister_regulator:
 	return ret;
 }
 
-static int palmas_remove(struct platform_device *pdev)
+static int palmas_regulators_remove(struct platform_device *pdev)
 {
 	struct palmas_pmic *pmic = platform_get_drvdata(pdev);
 	int id;
@@ -819,8 +819,8 @@ static struct platform_driver palmas_driver = {
 		.of_match_table = of_palmas_match_tbl,
 		.owner = THIS_MODULE,
 	},
-	.probe = palmas_probe,
-	.remove = palmas_remove,
+	.probe = palmas_regulators_probe,
+	.remove = palmas_regulators_remove,
 };
 
 static int __init palmas_init(void)
-- 
1.7.1.1

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 1/2] regulator: palmas: rename probe/remove callback functions
@ 2013-03-18  9:29   ` Laxman Dewangan
  0 siblings, 0 replies; 14+ messages in thread
From: Laxman Dewangan @ 2013-03-18  9:29 UTC (permalink / raw)
  To: broonie; +Cc: linux-kernel, swarren, linux-tegra, lrg, Laxman Dewangan

When palmas regulator probe creates stack dump during initialization
due to some crash, it prints the call trace as follows:
[3.166321] [<c028fa20>] (_regmap_read+0x5c/0xa8) from [<c028fab0>] (regmap_read+0x44/0x5c)
[3.174669] [<c028fab0>] (regmap_read+0x44/0x5c) from [<c023062c>] (palmas_probe+0x240/0x7d0)
[3.183193] [<c023062c>] (palmas_probe+0x240/0x7d0) from [<c0284064>] (platform_drv_probe+0x14/0x18)
[3.192322] [<c0284064>] (platform_drv_probe+0x14/0x18) from [<c0282ee4>] (driver_probe_device+0x104/0x214)
[3.202055] [<c0282ee4>] (driver_probe_device+0x104/0x214) from [<c028167c>] (bus_for_each_drv+0x5c/0x88)

The palmas_probe is current name but it helps on debugging if the
function name is more appropriate to the sub-module name.

Renaming the palmas_probe() to palmas_regulator_probe() and
palmas_remove() to palams_regulator_remove().

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
 drivers/regulator/palmas-regulator.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
index a9b558e..4a45942 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -582,7 +582,7 @@ static void palmas_dt_to_pdata(struct device *dev,
 }
 
 
-static int palmas_probe(struct platform_device *pdev)
+static int palmas_regulators_probe(struct platform_device *pdev)
 {
 	struct palmas *palmas = dev_get_drvdata(pdev->dev.parent);
 	struct palmas_pmic_platform_data *pdata = pdev->dev.platform_data;
@@ -791,7 +791,7 @@ err_unregister_regulator:
 	return ret;
 }
 
-static int palmas_remove(struct platform_device *pdev)
+static int palmas_regulators_remove(struct platform_device *pdev)
 {
 	struct palmas_pmic *pmic = platform_get_drvdata(pdev);
 	int id;
@@ -819,8 +819,8 @@ static struct platform_driver palmas_driver = {
 		.of_match_table = of_palmas_match_tbl,
 		.owner = THIS_MODULE,
 	},
-	.probe = palmas_probe,
-	.remove = palmas_remove,
+	.probe = palmas_regulators_probe,
+	.remove = palmas_regulators_remove,
 };
 
 static int __init palmas_init(void)
-- 
1.7.1.1


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/2] regulator: palmas: add input supply names
       [not found] ` <20130320123128.GM28775@opensource.wolfsonmicro.com>
@ 2013-03-20 12:54       ` Laxman Dewangan
  0 siblings, 0 replies; 14+ messages in thread
From: Laxman Dewangan @ 2013-03-20 12:54 UTC (permalink / raw)
  To: Mark Brown
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stephen Warren,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA, lrg-l0cyMroinI0

On Wednesday 20 March 2013 06:01 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Mon, Mar 18, 2013 at 02:59:48PM +0530, Laxman Dewangan wrote:
>
> There's something odd about several recent patch serieses you've posted,
> they end up with patch 2 before instead of after patch 1.  Anyway...

I generally send a patches on single git-send command
git send-emal --to=ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org 0000.patch 0001.patch

So file names are in seq but not sure why it is not on seq. Something 
mail exchange  resuffle.
Probably I need to send one by one...


>
>> +		if (config.init_data)
>> +			pmic->desc[id].supply_name = palmas_regs_info[id].sname;
>> +
> This looks wrong...  why is it conditional on init_data?

Some of the rails are not used in board and hence their inputs are also 
left floating (unconnected). In this case, during DT population, I did 
not put entry
i.e. if ldo1 is not used then ldo1-in is not connected on board and hence
entry on DT

ldo1-in-supply=<&xyzreg>;

is not there.

The regulator core register the regulator even if there is NULL 
init_data and in this case, it tries to findout the input-supply 
(provided through desc->supply_name) and it fails to find out the supply 
handle and so regulator register fails cause all regulator registration 
to fail.

So providing the dec->supply_name only in case of valid init_data.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/2] regulator: palmas: add input supply names
@ 2013-03-20 12:54       ` Laxman Dewangan
  0 siblings, 0 replies; 14+ messages in thread
From: Laxman Dewangan @ 2013-03-20 12:54 UTC (permalink / raw)
  To: Mark Brown; +Cc: linux-kernel, Stephen Warren, linux-tegra, lrg

On Wednesday 20 March 2013 06:01 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Mon, Mar 18, 2013 at 02:59:48PM +0530, Laxman Dewangan wrote:
>
> There's something odd about several recent patch serieses you've posted,
> they end up with patch 2 before instead of after patch 1.  Anyway...

I generally send a patches on single git-send command
git send-emal --to=ldewangan@nvidia.com 0000.patch 0001.patch

So file names are in seq but not sure why it is not on seq. Something 
mail exchange  resuffle.
Probably I need to send one by one...


>
>> +		if (config.init_data)
>> +			pmic->desc[id].supply_name = palmas_regs_info[id].sname;
>> +
> This looks wrong...  why is it conditional on init_data?

Some of the rails are not used in board and hence their inputs are also 
left floating (unconnected). In this case, during DT population, I did 
not put entry
i.e. if ldo1 is not used then ldo1-in is not connected on board and hence
entry on DT

ldo1-in-supply=<&xyzreg>;

is not there.

The regulator core register the regulator even if there is NULL 
init_data and in this case, it tries to findout the input-supply 
(provided through desc->supply_name) and it fails to find out the supply 
handle and so regulator register fails cause all regulator registration 
to fail.

So providing the dec->supply_name only in case of valid init_data.




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/2] regulator: palmas: add input supply names
       [not found]       ` <20130320132531.GO28775@opensource.wolfsonmicro.com>
@ 2013-03-20 13:32             ` Laxman Dewangan
  0 siblings, 0 replies; 14+ messages in thread
From: Laxman Dewangan @ 2013-03-20 13:32 UTC (permalink / raw)
  To: Mark Brown
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stephen Warren,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA, lrg-l0cyMroinI0

On Wednesday 20 March 2013 06:55 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Wed, Mar 20, 2013 at 06:24:54PM +0530, Laxman Dewangan wrote:
>
>> The regulator core register the regulator even if there is NULL
>> init_data and in this case, it tries to findout the input-supply
>> (provided through desc->supply_name) and it fails to find out the
>> supply handle and so regulator register fails cause all regulator
>> registration to fail.
>> So providing the dec->supply_name only in case of valid init_data.
> This works fine if you have a device per regulator instead of a device
> for all the regulators on the chip...  I would be inclined to address
> this by providing a "floating" supply and connecting everythinng to
> that.
I am fine with adding floating supply similar to below and connect all 
non-connected supply pins to this.

                 floating: regulator@1 {
                         compatible = "regulator-fixed";
                         reg = <1>;
                         regulator-name = "floating";
                 };

If this is fine then I will respin the patch to remove condition.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/2] regulator: palmas: add input supply names
@ 2013-03-20 13:32             ` Laxman Dewangan
  0 siblings, 0 replies; 14+ messages in thread
From: Laxman Dewangan @ 2013-03-20 13:32 UTC (permalink / raw)
  To: Mark Brown; +Cc: linux-kernel, Stephen Warren, linux-tegra, lrg

On Wednesday 20 March 2013 06:55 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Wed, Mar 20, 2013 at 06:24:54PM +0530, Laxman Dewangan wrote:
>
>> The regulator core register the regulator even if there is NULL
>> init_data and in this case, it tries to findout the input-supply
>> (provided through desc->supply_name) and it fails to find out the
>> supply handle and so regulator register fails cause all regulator
>> registration to fail.
>> So providing the dec->supply_name only in case of valid init_data.
> This works fine if you have a device per regulator instead of a device
> for all the regulators on the chip...  I would be inclined to address
> this by providing a "floating" supply and connecting everythinng to
> that.
I am fine with adding floating supply similar to below and connect all 
non-connected supply pins to this.

                 floating: regulator@1 {
                         compatible = "regulator-fixed";
                         reg = <1>;
                         regulator-name = "floating";
                 };

If this is fine then I will respin the patch to remove condition.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/2] regulator: palmas: add input supply names
  2013-03-20 12:54       ` Laxman Dewangan
@ 2013-03-20 16:07           ` Stephen Warren
  -1 siblings, 0 replies; 14+ messages in thread
From: Stephen Warren @ 2013-03-20 16:07 UTC (permalink / raw)
  To: Laxman Dewangan
  Cc: Mark Brown, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stephen Warren,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA, lrg-l0cyMroinI0

On 03/20/2013 06:54 AM, Laxman Dewangan wrote:
> On Wednesday 20 March 2013 06:01 PM, Mark Brown wrote:
>> * PGP Signed by an unknown key
>>
>> On Mon, Mar 18, 2013 at 02:59:48PM +0530, Laxman Dewangan wrote:
>>
>> There's something odd about several recent patch serieses you've posted,
>> they end up with patch 2 before instead of after patch 1.  Anyway...
> 
> I generally send a patches on single git-send command
> git send-emal --to=ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org 0000.patch 0001.patch

Don't do that; send *.patch. If you don't, then patches 2..n don't end
up being "in-reply-to" patch 1, so they won't show up as a single email
thread.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/2] regulator: palmas: add input supply names
@ 2013-03-20 16:07           ` Stephen Warren
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Warren @ 2013-03-20 16:07 UTC (permalink / raw)
  To: Laxman Dewangan
  Cc: Mark Brown, linux-kernel, Stephen Warren, linux-tegra, lrg

On 03/20/2013 06:54 AM, Laxman Dewangan wrote:
> On Wednesday 20 March 2013 06:01 PM, Mark Brown wrote:
>> * PGP Signed by an unknown key
>>
>> On Mon, Mar 18, 2013 at 02:59:48PM +0530, Laxman Dewangan wrote:
>>
>> There's something odd about several recent patch serieses you've posted,
>> they end up with patch 2 before instead of after patch 1.  Anyway...
> 
> I generally send a patches on single git-send command
> git send-emal --to=ldewangan@nvidia.com 0000.patch 0001.patch

Don't do that; send *.patch. If you don't, then patches 2..n don't end
up being "in-reply-to" patch 1, so they won't show up as a single email
thread.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/2] regulator: palmas: add input supply names
       [not found]           ` <20130320163833.GT28775@opensource.wolfsonmicro.com>
@ 2013-03-20 16:42                 ` Stephen Warren
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Warren @ 2013-03-20 16:42 UTC (permalink / raw)
  To: Mark Brown
  Cc: Laxman Dewangan, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	Stephen Warren, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
	lrg-l0cyMroinI0

On 03/20/2013 10:38 AM, Mark Brown wrote:
> On Wed, Mar 20, 2013 at 10:07:17AM -0600, Stephen Warren wrote:
>> On 03/20/2013 06:54 AM, Laxman Dewangan wrote:
> 
>>> I generally send a patches on single git-send command git
>>> send-emal --to=ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org 0000.patch 0001.patch
> 
>> Don't do that; send *.patch. If you don't, then patches 2..n
>> don't end up being "in-reply-to" patch 1, so they won't show up
>> as a single email thread.
> 
> The two should be equivalent (though the glob is much easier to
> type)? The result of the globbing ought to be what Laxman is typing
> by hand assuming that he's getting the order correct.

If you send *.patch at once, git send-email adds an in-reply-to header
to the email which sets up the threading. If you send the patches
1-by-1, this header isn't added, since git send-email doesn't have a
clue what message ID it chose for patch 1. Unless you pass the
--in-reply-to command-line option, that is.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/2] regulator: palmas: add input supply names
@ 2013-03-20 16:42                 ` Stephen Warren
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Warren @ 2013-03-20 16:42 UTC (permalink / raw)
  To: Mark Brown
  Cc: Laxman Dewangan, linux-kernel, Stephen Warren, linux-tegra, lrg

On 03/20/2013 10:38 AM, Mark Brown wrote:
> On Wed, Mar 20, 2013 at 10:07:17AM -0600, Stephen Warren wrote:
>> On 03/20/2013 06:54 AM, Laxman Dewangan wrote:
> 
>>> I generally send a patches on single git-send command git
>>> send-emal --to=ldewangan@nvidia.com 0000.patch 0001.patch
> 
>> Don't do that; send *.patch. If you don't, then patches 2..n
>> don't end up being "in-reply-to" patch 1, so they won't show up
>> as a single email thread.
> 
> The two should be equivalent (though the glob is much easier to
> type)? The result of the globbing ought to be what Laxman is typing
> by hand assuming that he's getting the order correct.

If you send *.patch at once, git send-email adds an in-reply-to header
to the email which sets up the threading. If you send the patches
1-by-1, this header isn't added, since git send-email doesn't have a
clue what message ID it chose for patch 1. Unless you pass the
--in-reply-to command-line option, that is.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/2] regulator: palmas: add input supply names
       [not found]                 ` <20130320165227.GU28775@opensource.wolfsonmicro.com>
@ 2013-03-20 16:56                       ` Stephen Warren
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Warren @ 2013-03-20 16:56 UTC (permalink / raw)
  To: Mark Brown
  Cc: Laxman Dewangan, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	Stephen Warren, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
	lrg-l0cyMroinI0

On 03/20/2013 10:52 AM, Mark Brown wrote:
> On Wed, Mar 20, 2013 at 10:42:26AM -0600, Stephen Warren wrote:
>> On 03/20/2013 10:38 AM, Mark Brown wrote:
>>> On Wed, Mar 20, 2013 at 10:07:17AM -0600, Stephen Warren
>>> wrote:
>>>> On 03/20/2013 06:54 AM, Laxman Dewangan wrote:
> 
>>>>> I generally send a patches on single git-send command git 
>>>>> send-emal --to=ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org 0000.patch 0001.patch
> 
>>>> Don't do that; send *.patch. If you don't, then patches 2..n 
>>>> don't end up being "in-reply-to" patch 1, so they won't show
>>>> up as a single email thread.
> 
>>> The two should be equivalent (though the glob is much easier
>>> to type)? The result of the globbing ought to be what Laxman is
>>> typing by hand assuming that he's getting the order correct.
> 
>> If you send *.patch at once, git send-email adds an in-reply-to
>> header to the email which sets up the threading. If you send the
>> patches 1-by-1, this header isn't added, since git send-email
>> doesn't have a clue what message ID it chose for patch 1. Unless
>> you pass the --in-reply-to command-line option, that is.
> 
> Indeed - I think you may have quoted the wrong bit of Laxman's
> mail there?  The bit you're replying to is doing it as a single
> command, though he did talk about doing this in multiple commands
> elsewhere in his mail.

Oh right yes. I'd seen 0000.patch and not that there were multiple
entries in the command-line that listed (I assume) all the files.
Sorry for the noise.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/2] regulator: palmas: add input supply names
@ 2013-03-20 16:56                       ` Stephen Warren
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Warren @ 2013-03-20 16:56 UTC (permalink / raw)
  To: Mark Brown
  Cc: Laxman Dewangan, linux-kernel, Stephen Warren, linux-tegra, lrg

On 03/20/2013 10:52 AM, Mark Brown wrote:
> On Wed, Mar 20, 2013 at 10:42:26AM -0600, Stephen Warren wrote:
>> On 03/20/2013 10:38 AM, Mark Brown wrote:
>>> On Wed, Mar 20, 2013 at 10:07:17AM -0600, Stephen Warren
>>> wrote:
>>>> On 03/20/2013 06:54 AM, Laxman Dewangan wrote:
> 
>>>>> I generally send a patches on single git-send command git 
>>>>> send-emal --to=ldewangan@nvidia.com 0000.patch 0001.patch
> 
>>>> Don't do that; send *.patch. If you don't, then patches 2..n 
>>>> don't end up being "in-reply-to" patch 1, so they won't show
>>>> up as a single email thread.
> 
>>> The two should be equivalent (though the glob is much easier
>>> to type)? The result of the globbing ought to be what Laxman is
>>> typing by hand assuming that he's getting the order correct.
> 
>> If you send *.patch at once, git send-email adds an in-reply-to
>> header to the email which sets up the threading. If you send the
>> patches 1-by-1, this header isn't added, since git send-email
>> doesn't have a clue what message ID it chose for patch 1. Unless
>> you pass the --in-reply-to command-line option, that is.
> 
> Indeed - I think you may have quoted the wrong bit of Laxman's
> mail there?  The bit you're replying to is doing it as a single
> command, though he did talk about doing this in multiple commands
> elsewhere in his mail.

Oh right yes. I'd seen 0000.patch and not that there were multiple
entries in the command-line that listed (I assume) all the files.
Sorry for the noise.

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2013-03-20 16:56 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-18  9:29 [PATCH 2/2] regulator: palmas: add input supply names Laxman Dewangan
2013-03-18  9:29 ` Laxman Dewangan
2013-03-18  9:29 ` [PATCH 1/2] regulator: palmas: rename probe/remove callback functions Laxman Dewangan
2013-03-18  9:29   ` Laxman Dewangan
     [not found] ` <20130320123128.GM28775@opensource.wolfsonmicro.com>
     [not found]   ` <20130320123128.GM28775-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2013-03-20 12:54     ` [PATCH 2/2] regulator: palmas: add input supply names Laxman Dewangan
2013-03-20 12:54       ` Laxman Dewangan
     [not found]       ` <20130320132531.GO28775@opensource.wolfsonmicro.com>
     [not found]         ` <20130320132531.GO28775-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2013-03-20 13:32           ` Laxman Dewangan
2013-03-20 13:32             ` Laxman Dewangan
     [not found]       ` <5149B19E.90400-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-03-20 16:07         ` Stephen Warren
2013-03-20 16:07           ` Stephen Warren
     [not found]           ` <20130320163833.GT28775@opensource.wolfsonmicro.com>
     [not found]             ` <20130320163833.GT28775-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2013-03-20 16:42               ` Stephen Warren
2013-03-20 16:42                 ` Stephen Warren
     [not found]                 ` <20130320165227.GU28775@opensource.wolfsonmicro.com>
     [not found]                   ` <20130320165227.GU28775-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2013-03-20 16:56                     ` Stephen Warren
2013-03-20 16:56                       ` Stephen Warren

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.