Currently the enable GPIO is being looked up on the regulator
device itself but that does not have its own DT node, this causes
the lookup to fail and the regulator not to get its GPIO. The DT
node is shared across the whole MFD and as such the lookup needs
to happen on that parent device. Moving the lookup to the parent
device also means devres can no longer be used as the life time
would attach to the wrong device.
Fixes: e1739e86f0cb ("regulator: arizona-ldo1: Look up a descriptor and pass to the core")
Reported-by: Matthias Reichl <[email protected]>
Signed-off-by: Charles Keepax <[email protected]>
---
Apologies for missing this again, we should have caught
this in our testing and thanks for reporting it.
Thanks,
Charles
drivers/regulator/arizona-ldo1.c | 27 ++++++++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
index f6d6a4ad9e8a..a981896c056a 100644
--- a/drivers/regulator/arizona-ldo1.c
+++ b/drivers/regulator/arizona-ldo1.c
@@ -36,6 +36,8 @@ struct arizona_ldo1 {
struct regulator_consumer_supply supply;
struct regulator_init_data init_data;
+
+ struct gpio_desc *ena_gpiod;
};
static int arizona_ldo1_hc_list_voltage(struct regulator_dev *rdev,
@@ -253,12 +255,17 @@ static int arizona_ldo1_common_init(struct platform_device *pdev,
}
}
- /* We assume that high output = regulator off */
- config.ena_gpiod = devm_gpiod_get_optional(&pdev->dev, "wlf,ldoena",
- GPIOD_OUT_HIGH);
+ /* We assume that high output = regulator off
+ * Don't use devm, since we need to get against the parent device
+ * so clean up would happen at the wrong time
+ */
+ config.ena_gpiod = gpiod_get_optional(parent_dev, "wlf,ldoena",
+ GPIOD_OUT_HIGH);
if (IS_ERR(config.ena_gpiod))
return PTR_ERR(config.ena_gpiod);
+ ldo1->ena_gpiod = config.ena_gpiod;
+
if (pdata->init_data)
config.init_data = pdata->init_data;
else
@@ -276,6 +283,9 @@ static int arizona_ldo1_common_init(struct platform_device *pdev,
of_node_put(config.of_node);
if (IS_ERR(ldo1->regulator)) {
+ if (config.ena_gpiod)
+ gpiod_put(config.ena_gpiod);
+
ret = PTR_ERR(ldo1->regulator);
dev_err(&pdev->dev, "Failed to register LDO1 supply: %d\n",
ret);
@@ -334,8 +344,19 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
return ret;
}
+static int arizona_ldo1_remove(struct platform_device *pdev)
+{
+ struct arizona_ldo1 *ldo1 = platform_get_drvdata(pdev);
+
+ if (ldo1->ena_gpiod)
+ gpiod_put(ldo1->ena_gpiod);
+
+ return 0;
+}
+
static struct platform_driver arizona_ldo1_driver = {
.probe = arizona_ldo1_probe,
+ .remove = arizona_ldo1_remove,
.driver = {
.name = "arizona-ldo1",
},
--
2.11.0
On Tue, Jun 19, 2018 at 10:32:45AM +0100, Charles Keepax wrote:
> Currently the enable GPIO is being looked up on the regulator
> device itself but that does not have its own DT node, this causes
> the lookup to fail and the regulator not to get its GPIO. The DT
> node is shared across the whole MFD and as such the lookup needs
> to happen on that parent device. Moving the lookup to the parent
> device also means devres can no longer be used as the life time
> would attach to the wrong device.
>
> Fixes: e1739e86f0cb ("regulator: arizona-ldo1: Look up a descriptor and pass to the core")
> Reported-by: Matthias Reichl <[email protected]>
> Signed-off-by: Charles Keepax <[email protected]>
Tested-by: Matthias Reichl <[email protected]>
> Apologies for missing this again, we should have caught
> this in our testing and thanks for reporting it.
No problem, and thank you a lot for the quick fix!
During testing I noticed another minor change introduced by
commit e1739e86f0cb, see comment inline below.
>
> Thanks,
> Charles
>
> drivers/regulator/arizona-ldo1.c | 27 ++++++++++++++++++++++++---
> 1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
> index f6d6a4ad9e8a..a981896c056a 100644
> --- a/drivers/regulator/arizona-ldo1.c
> +++ b/drivers/regulator/arizona-ldo1.c
> @@ -36,6 +36,8 @@ struct arizona_ldo1 {
>
> struct regulator_consumer_supply supply;
> struct regulator_init_data init_data;
> +
> + struct gpio_desc *ena_gpiod;
> };
>
> static int arizona_ldo1_hc_list_voltage(struct regulator_dev *rdev,
> @@ -253,12 +255,17 @@ static int arizona_ldo1_common_init(struct platform_device *pdev,
> }
> }
>
> - /* We assume that high output = regulator off */
> - config.ena_gpiod = devm_gpiod_get_optional(&pdev->dev, "wlf,ldoena",
> - GPIOD_OUT_HIGH);
> + /* We assume that high output = regulator off
> + * Don't use devm, since we need to get against the parent device
> + * so clean up would happen at the wrong time
> + */
> + config.ena_gpiod = gpiod_get_optional(parent_dev, "wlf,ldoena",
> + GPIOD_OUT_HIGH);
The WM5102 datasheet lists LDOENA as an active-high input,
so GPIOD_OUT_HIGH causes arizona-ldo1 to start up enabled.
Not sure about the other devices from the Arizona family.
I did some tests monitoring ldoena and reset gpios with my scope:
With commit e1739e86f0cb reverted ldoena changes from low to high
about 1.6ms before reset changes from low to high.
With your patch ldoena goes high about 11.5ms before reset goes high.
With your patch and GPIOD_OUT_HIGH changed to GPIOD_OUT_LOW
the delay is again about 1.6ms.
So I guess it'd be better to adjust the comment and change
to gpiod flag to GPIOD_OUT_LOW.
so long,
Hias
> if (IS_ERR(config.ena_gpiod))
> return PTR_ERR(config.ena_gpiod);
>
> + ldo1->ena_gpiod = config.ena_gpiod;
> +
> if (pdata->init_data)
> config.init_data = pdata->init_data;
> else
> @@ -276,6 +283,9 @@ static int arizona_ldo1_common_init(struct platform_device *pdev,
> of_node_put(config.of_node);
>
> if (IS_ERR(ldo1->regulator)) {
> + if (config.ena_gpiod)
> + gpiod_put(config.ena_gpiod);
> +
> ret = PTR_ERR(ldo1->regulator);
> dev_err(&pdev->dev, "Failed to register LDO1 supply: %d\n",
> ret);
> @@ -334,8 +344,19 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
> return ret;
> }
>
> +static int arizona_ldo1_remove(struct platform_device *pdev)
> +{
> + struct arizona_ldo1 *ldo1 = platform_get_drvdata(pdev);
> +
> + if (ldo1->ena_gpiod)
> + gpiod_put(ldo1->ena_gpiod);
> +
> + return 0;
> +}
> +
> static struct platform_driver arizona_ldo1_driver = {
> .probe = arizona_ldo1_probe,
> + .remove = arizona_ldo1_remove,
> .driver = {
> .name = "arizona-ldo1",
> },
> --
> 2.11.0
>
On Tue, Jun 19, 2018 at 02:24:33PM +0200, Matthias Reichl wrote:
> On Tue, Jun 19, 2018 at 10:32:45AM +0100, Charles Keepax wrote:
> > + config.ena_gpiod = gpiod_get_optional(parent_dev, "wlf,ldoena",
> > + GPIOD_OUT_HIGH);
>
> The WM5102 datasheet lists LDOENA as an active-high input,
> so GPIOD_OUT_HIGH causes arizona-ldo1 to start up enabled.
> Not sure about the other devices from the Arizona family.
>
Yeah all active high.
> I did some tests monitoring ldoena and reset gpios with my scope:
>
> With commit e1739e86f0cb reverted ldoena changes from low to high
> about 1.6ms before reset changes from low to high.
>
> With your patch ldoena goes high about 11.5ms before reset goes high.
>
> With your patch and GPIOD_OUT_HIGH changed to GPIOD_OUT_LOW
> the delay is again about 1.6ms.
>
> So I guess it'd be better to adjust the comment and change
> to gpiod flag to GPIOD_OUT_LOW.
Yeah I am inclined to agree would be better to keep the behaviour
the same as it has always been given these parts are fairly
mature I will respin the patch to add that change too.
Thanks,
Charles