[PATCH] regulator: fix: enable gpio when requested

[PATCH] regulator: fix: enable gpio when requested

[Mark Kettenis]

The fix in commit b7adcdd073c0 has the side-effect that the regulator
will be disabled when requesting the relevant gpio in
regulator_common_ofdata_to_platdata() and enabled in
regulator_pre_probe() when the regulator was already enabled.
This leads to a short interruption in the 3.3V power to the PCIe
slot on the firefly-rk3399 which makes an ADATA SX8000NP NVMe SSD
unhappy.

Fix this by setting the GPIOD_IS_OUT_ACTIVE flag again when the
'regulator-boot-on' property is set, but check for this property
explicitly instead of relying on the "boot_on" member of
the uclass platdata.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
---
 drivers/power/regulator/regulator-uclass.c | 3 ---
 drivers/power/regulator/regulator_common.c | 2 ++
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/power/regulator/regulator-uclass.c b/drivers/power/regulator/regulator-uclass.c
index c9d26344d7..90961de95c 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -464,9 +464,6 @@ static int regulator_pre_probe(struct udevice *dev)
 	    (uc_pdata->min_uA == uc_pdata->max_uA))
 		uc_pdata->flags |= REGULATOR_FLAG_AUTOSET_UA;
 
-	if (uc_pdata->boot_on)
-		regulator_set_enable(dev, uc_pdata->boot_on);
-
 	return 0;
 }
 
diff --git a/drivers/power/regulator/regulator_common.c b/drivers/power/regulator/regulator_common.c
index 33b73b7c2f..bc13b88476 100644
--- a/drivers/power/regulator/regulator_common.c
+++ b/drivers/power/regulator/regulator_common.c
@@ -17,6 +17,8 @@ int regulator_common_ofdata_to_platdata(struct udevice *dev,
 
 	if (!dev_read_bool(dev, "enable-active-high"))
 		flags |= GPIOD_ACTIVE_LOW;
+	if (dev_read_bool(dev, "regulator-boot-on"))
+		flags |= GPIOD_IS_OUT_ACTIVE;
 
 	/* Get optional enable GPIO desc */
 	gpio = &dev_pdata->gpio;
-- 
2.26.2

[PATCH] regulator: fix: enable gpio when requested

[Patrice CHOTARD]

Hi Mark

On 4/27/20 11:09 AM, Mark Kettenis wrote:
> The fix in commit b7adcdd073c0 has the side-effect that the regulator
> will be disabled when requesting the relevant gpio in
> regulator_common_ofdata_to_platdata() and enabled in
> regulator_pre_probe() when the regulator was already enabled.
> This leads to a short interruption in the 3.3V power to the PCIe
> slot on the firefly-rk3399 which makes an ADATA SX8000NP NVMe SSD
> unhappy.
>
> Fix this by setting the GPIOD_IS_OUT_ACTIVE flag again when the
> 'regulator-boot-on' property is set, but check for this property
> explicitly instead of relying on the "boot_on" member of
> the uclass platdata.
>
> Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
> ---
>  drivers/power/regulator/regulator-uclass.c | 3 ---
>  drivers/power/regulator/regulator_common.c | 2 ++
>  2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/power/regulator/regulator-uclass.c b/drivers/power/regulator/regulator-uclass.c
> index c9d26344d7..90961de95c 100644
> --- a/drivers/power/regulator/regulator-uclass.c
> +++ b/drivers/power/regulator/regulator-uclass.c
> @@ -464,9 +464,6 @@ static int regulator_pre_probe(struct udevice *dev)
>  	    (uc_pdata->min_uA == uc_pdata->max_uA))
>  		uc_pdata->flags |= REGULATOR_FLAG_AUTOSET_UA;
>  
> -	if (uc_pdata->boot_on)
> -		regulator_set_enable(dev, uc_pdata->boot_on);
> -
>  	return 0;
>  }
>  
> diff --git a/drivers/power/regulator/regulator_common.c b/drivers/power/regulator/regulator_common.c
> index 33b73b7c2f..bc13b88476 100644
> --- a/drivers/power/regulator/regulator_common.c
> +++ b/drivers/power/regulator/regulator_common.c
> @@ -17,6 +17,8 @@ int regulator_common_ofdata_to_platdata(struct udevice *dev,
>  
>  	if (!dev_read_bool(dev, "enable-active-high"))
>  		flags |= GPIOD_ACTIVE_LOW;
> +	if (dev_read_bool(dev, "regulator-boot-on"))
> +		flags |= GPIOD_IS_OUT_ACTIVE;
>  
>  	/* Get optional enable GPIO desc */
>  	gpio = &dev_pdata->gpio;

Tested on STM32MP1 EV1 and DK2 boards in basic and trusted mode

Tested-by: Patrice Chotard <patrice.chotard@st.com>

Thanks

[PATCH] regulator: fix: enable gpio when requested

[Simon Glass]

Hi Mark,

On Mon, 27 Apr 2020 at 03:09, Mark Kettenis <kettenis@openbsd.org> wrote:
>
> The fix in commit b7adcdd073c0 has the side-effect that the regulator
> will be disabled when requesting the relevant gpio in
> regulator_common_ofdata_to_platdata() and enabled in
> regulator_pre_probe() when the regulator was already enabled.
> This leads to a short interruption in the 3.3V power to the PCIe
> slot on the firefly-rk3399 which makes an ADATA SX8000NP NVMe SSD
> unhappy.
>
> Fix this by setting the GPIOD_IS_OUT_ACTIVE flag again when the
> 'regulator-boot-on' property is set, but check for this property
> explicitly instead of relying on the "boot_on" member of
> the uclass platdata.
>
> Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
> ---
>  drivers/power/regulator/regulator-uclass.c | 3 ---
>  drivers/power/regulator/regulator_common.c | 2 ++
>  2 files changed, 2 insertions(+), 3 deletions(-)

Should this have a Fixed: tag?

Regards,
Simon

[PATCH] regulator: fix: enable gpio when requested

[Lukasz Majewski]

Hi Mark,

> The fix in commit b7adcdd073c0 has the side-effect that the regulator
> will be disabled when requesting the relevant gpio in
> regulator_common_ofdata_to_platdata() and enabled in
> regulator_pre_probe() when the regulator was already enabled.
> This leads to a short interruption in the 3.3V power to the PCIe
> slot on the firefly-rk3399 which makes an ADATA SX8000NP NVMe SSD
> unhappy.
> 
> Fix this by setting the GPIOD_IS_OUT_ACTIVE flag again when the
> 'regulator-boot-on' property is set, but check for this property
> explicitly instead of relying on the "boot_on" member of
> the uclass platdata.
> 
> Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
> ---
>  drivers/power/regulator/regulator-uclass.c | 3 ---
>  drivers/power/regulator/regulator_common.c | 2 ++
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/power/regulator/regulator-uclass.c
> b/drivers/power/regulator/regulator-uclass.c index
> c9d26344d7..90961de95c 100644 ---
> a/drivers/power/regulator/regulator-uclass.c +++
> b/drivers/power/regulator/regulator-uclass.c @@ -464,9 +464,6 @@
> static int regulator_pre_probe(struct udevice *dev) (uc_pdata->min_uA
> == uc_pdata->max_uA)) uc_pdata->flags |= REGULATOR_FLAG_AUTOSET_UA;
>  
> -	if (uc_pdata->boot_on)
> -		regulator_set_enable(dev, uc_pdata->boot_on);
> -
>  	return 0;
>  }
>  
> diff --git a/drivers/power/regulator/regulator_common.c
> b/drivers/power/regulator/regulator_common.c index
> 33b73b7c2f..bc13b88476 100644 ---
> a/drivers/power/regulator/regulator_common.c +++
> b/drivers/power/regulator/regulator_common.c @@ -17,6 +17,8 @@ int
> regulator_common_ofdata_to_platdata(struct udevice *dev, 
>  	if (!dev_read_bool(dev, "enable-active-high"))
>  		flags |= GPIOD_ACTIVE_LOW;
> +	if (dev_read_bool(dev, "regulator-boot-on"))
> +		flags |= GPIOD_IS_OUT_ACTIVE;
>  
>  	/* Get optional enable GPIO desc */
>  	gpio = &dev_pdata->gpio;

Sorry, but this is a simple revert of my commit and breaks use cases
described in the commit message of this fix.

Do you see some kind of "glitch" on the gpio in
regulator_common_of_platdata?

The regulator-boot-on property [1] shall prevent from the issue you
described in the commit message of this revert.

Links:
[1] -
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/regulator/regulator.yaml#L40

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200428/4948ed4c/attachment.sig>

[PATCH] regulator: fix: enable gpio when requested

[Mark Kettenis]

> Date: Tue, 28 Apr 2020 06:24:10 +0200
> From: Lukasz Majewski <lukma@denx.de>

Hi Lukasz,

> Hi Mark,
> 
> > The fix in commit b7adcdd073c0 has the side-effect that the regulator
> > will be disabled when requesting the relevant gpio in
> > regulator_common_ofdata_to_platdata() and enabled in
> > regulator_pre_probe() when the regulator was already enabled.
> > This leads to a short interruption in the 3.3V power to the PCIe
> > slot on the firefly-rk3399 which makes an ADATA SX8000NP NVMe SSD
> > unhappy.
> > 
> > Fix this by setting the GPIOD_IS_OUT_ACTIVE flag again when the
> > 'regulator-boot-on' property is set, but check for this property
> > explicitly instead of relying on the "boot_on" member of
> > the uclass platdata.
> > 
> > Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
> > ---
> >  drivers/power/regulator/regulator-uclass.c | 3 ---
> >  drivers/power/regulator/regulator_common.c | 2 ++
> >  2 files changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/power/regulator/regulator-uclass.c
> > b/drivers/power/regulator/regulator-uclass.c index
> > c9d26344d7..90961de95c 100644 ---
> > a/drivers/power/regulator/regulator-uclass.c +++
> > b/drivers/power/regulator/regulator-uclass.c @@ -464,9 +464,6 @@
> > static int regulator_pre_probe(struct udevice *dev) (uc_pdata->min_uA
> > == uc_pdata->max_uA)) uc_pdata->flags |= REGULATOR_FLAG_AUTOSET_UA;
> >  
> > -	if (uc_pdata->boot_on)
> > -		regulator_set_enable(dev, uc_pdata->boot_on);
> > -
> >  	return 0;
> >  }
> >  
> > diff --git a/drivers/power/regulator/regulator_common.c
> > b/drivers/power/regulator/regulator_common.c index
> > 33b73b7c2f..bc13b88476 100644 ---
> > a/drivers/power/regulator/regulator_common.c +++
> > b/drivers/power/regulator/regulator_common.c @@ -17,6 +17,8 @@ int
> > regulator_common_ofdata_to_platdata(struct udevice *dev, 
> >  	if (!dev_read_bool(dev, "enable-active-high"))
> >  		flags |= GPIOD_ACTIVE_LOW;
> > +	if (dev_read_bool(dev, "regulator-boot-on"))
> > +		flags |= GPIOD_IS_OUT_ACTIVE;
> >  
> >  	/* Get optional enable GPIO desc */
> >  	gpio = &dev_pdata->gpio;
> 
> Sorry, but this is a simple revert of my commit and breaks use cases
> described in the commit message of this fix.

No, it isn't a simple revert, and I don't think it will break the i.MX
ethernet driver.

I think the analysis in the commit message is a bit flawed.  I don't
think there was something actually wrong with commit e8e9715df2d4
because at the time regulator_pre_probe() was called before
regulator_common_ofdata_to_platdata().

This was changed in 29f7d05a347ab ("dm: core: Move
ofdata_to_platdata() call earlier"), which was the commit git bisect
led me to.  After that commit the boot_on member no longer being set.

My diff is indeed mostly a revert of yours, but it replaces the
boot_on member check with an explicit check of the "boot-on" property.
As a result the GPIOD_IS_OUT_ACTIVE flag is set correctly and the
regulator should be turned on (or stay on in my case).

> Do you see some kind of "glitch" on the gpio in
> regulator_common_of_platdata?

I don't have the tools to actually measure the pin but yes all the
evidence points to a glitch.  I also instrumented the actual gpio
driver and it defenitely is setting the pin low (0) and setting it
high (1) again later.  So I think it is essential that
GPIOD_IS_OUT_ACTIVE is set when the gpio is set in the
gpio_request_by_name() call.  Enabling it later later isn't good
enough.

What I'm seeing on my hardware is that the NVMe device is still
present on the PCIe bus, but reports a bogus size and a different
firmware version string.  I'm fairly certain that a glitch on the 3.3V
pin is interrupting the load of the firmware that is stored on the
card itself.  When this happens, the only thing that fixes it is a
complete power cycle of the board.

> The regulator-boot-on property [1] shall prevent from the issue you
> described in the commit message of this revert.
> 
> Links:
> [1] -
> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/regulator/regulator.yaml#L40
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de

[PATCH] regulator: fix: enable gpio when requested

[Lukasz Majewski]

Hi Mark,

> > Date: Tue, 28 Apr 2020 06:24:10 +0200
> > From: Lukasz Majewski <lukma@denx.de>  
> 
> Hi Lukasz,
> 
> > Hi Mark,
> >   
> > > The fix in commit b7adcdd073c0 has the side-effect that the
> > > regulator will be disabled when requesting the relevant gpio in
> > > regulator_common_ofdata_to_platdata() and enabled in
> > > regulator_pre_probe() when the regulator was already enabled.
> > > This leads to a short interruption in the 3.3V power to the PCIe
> > > slot on the firefly-rk3399 which makes an ADATA SX8000NP NVMe SSD
> > > unhappy.
> > > 
> > > Fix this by setting the GPIOD_IS_OUT_ACTIVE flag again when the
> > > 'regulator-boot-on' property is set, but check for this property
> > > explicitly instead of relying on the "boot_on" member of
> > > the uclass platdata.
> > > 
> > > Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
> > > ---
> > >  drivers/power/regulator/regulator-uclass.c | 3 ---
> > >  drivers/power/regulator/regulator_common.c | 2 ++
> > >  2 files changed, 2 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/power/regulator/regulator-uclass.c
> > > b/drivers/power/regulator/regulator-uclass.c index
> > > c9d26344d7..90961de95c 100644 ---
> > > a/drivers/power/regulator/regulator-uclass.c +++
> > > b/drivers/power/regulator/regulator-uclass.c @@ -464,9 +464,6 @@
> > > static int regulator_pre_probe(struct udevice *dev)
> > > (uc_pdata->min_uA == uc_pdata->max_uA)) uc_pdata->flags |=
> > > REGULATOR_FLAG_AUTOSET_UA; 
> > > -	if (uc_pdata->boot_on)
> > > -		regulator_set_enable(dev, uc_pdata->boot_on);
> > > -
> > >  	return 0;
> > >  }
> > >  
> > > diff --git a/drivers/power/regulator/regulator_common.c
> > > b/drivers/power/regulator/regulator_common.c index
> > > 33b73b7c2f..bc13b88476 100644 ---
> > > a/drivers/power/regulator/regulator_common.c +++
> > > b/drivers/power/regulator/regulator_common.c @@ -17,6 +17,8 @@ int
> > > regulator_common_ofdata_to_platdata(struct udevice *dev, 
> > >  	if (!dev_read_bool(dev, "enable-active-high"))
> > >  		flags |= GPIOD_ACTIVE_LOW;
> > > +	if (dev_read_bool(dev, "regulator-boot-on"))
> > > +		flags |= GPIOD_IS_OUT_ACTIVE;
> > >  
> > >  	/* Get optional enable GPIO desc */
> > >  	gpio = &dev_pdata->gpio;  
> > 
> > Sorry, but this is a simple revert of my commit and breaks use cases
> > described in the commit message of this fix.  
> 
> No, it isn't a simple revert, and I don't think it will break the i.MX
> ethernet driver.

I need to check this - as this issue was critical for i.MX53 (it caused
the board not being able to update U-Boot after this change).

> 
> I think the analysis in the commit message is a bit flawed.  I don't
> think there was something actually wrong with commit e8e9715df2d4
> because at the time regulator_pre_probe() was called before
> regulator_common_ofdata_to_platdata().
> 
> This was changed in 29f7d05a347ab ("dm: core: Move
> ofdata_to_platdata() call earlier"), which was the commit git bisect
> led me to.  After that commit the boot_on member no longer being set.
> 
> My diff is indeed mostly a revert of yours, but it replaces the
> boot_on member check with an explicit check of the "boot-on" property.
> As a result the GPIOD_IS_OUT_ACTIVE flag is set correctly and the
> regulator should be turned on (or stay on in my case).

I must have overlooked the difference. In my case the regulator had to
be powered up early (in the preprobe) so ETH initialization would be
performed with enabled power.

> 
> > Do you see some kind of "glitch" on the gpio in
> > regulator_common_of_platdata?  
> 
> I don't have the tools to actually measure the pin but yes all the
> evidence points to a glitch.  I also instrumented the actual gpio
> driver and it defenitely is setting the pin low (0) and setting it
> high (1) again later.  So I think it is essential that
> GPIOD_IS_OUT_ACTIVE is set when the gpio is set in the
> gpio_request_by_name() call.  Enabling it later later isn't good
> enough.
> 
> What I'm seeing on my hardware is that the NVMe device is still
> present on the PCIe bus, but reports a bogus size and a different
> firmware version string.  I'm fairly certain that a glitch on the 3.3V
> pin is interrupting the load of the firmware that is stored on the
> card itself.  When this happens, the only thing that fixes it is a
> complete power cycle of the board.
> 
> > The regulator-boot-on property [1] shall prevent from the issue you
> > described in the commit message of this revert.
> > 
> > Links:
> > [1] -
> > https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/regulator/regulator.yaml#L40
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > lukma at denx.de  




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200428/5013ce5b/attachment.sig>

[PATCH] regulator: fix: enable gpio when requested

[Mark Kettenis]

> Date: Tue, 28 Apr 2020 20:26:09 +0200
> From: Lukasz Majewski <lukma@denx.de>

Ping?

> Hi Mark,
> 
> > > Date: Tue, 28 Apr 2020 06:24:10 +0200
> > > From: Lukasz Majewski <lukma@denx.de>  
> > 
> > Hi Lukasz,
> > 
> > > Hi Mark,
> > >   
> > > > The fix in commit b7adcdd073c0 has the side-effect that the
> > > > regulator will be disabled when requesting the relevant gpio in
> > > > regulator_common_ofdata_to_platdata() and enabled in
> > > > regulator_pre_probe() when the regulator was already enabled.
> > > > This leads to a short interruption in the 3.3V power to the PCIe
> > > > slot on the firefly-rk3399 which makes an ADATA SX8000NP NVMe SSD
> > > > unhappy.
> > > > 
> > > > Fix this by setting the GPIOD_IS_OUT_ACTIVE flag again when the
> > > > 'regulator-boot-on' property is set, but check for this property
> > > > explicitly instead of relying on the "boot_on" member of
> > > > the uclass platdata.
> > > > 
> > > > Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
> > > > ---
> > > >  drivers/power/regulator/regulator-uclass.c | 3 ---
> > > >  drivers/power/regulator/regulator_common.c | 2 ++
> > > >  2 files changed, 2 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/power/regulator/regulator-uclass.c
> > > > b/drivers/power/regulator/regulator-uclass.c index
> > > > c9d26344d7..90961de95c 100644 ---
> > > > a/drivers/power/regulator/regulator-uclass.c +++
> > > > b/drivers/power/regulator/regulator-uclass.c @@ -464,9 +464,6 @@
> > > > static int regulator_pre_probe(struct udevice *dev)
> > > > (uc_pdata->min_uA == uc_pdata->max_uA)) uc_pdata->flags |=
> > > > REGULATOR_FLAG_AUTOSET_UA; 
> > > > -	if (uc_pdata->boot_on)
> > > > -		regulator_set_enable(dev, uc_pdata->boot_on);
> > > > -
> > > >  	return 0;
> > > >  }
> > > >  
> > > > diff --git a/drivers/power/regulator/regulator_common.c
> > > > b/drivers/power/regulator/regulator_common.c index
> > > > 33b73b7c2f..bc13b88476 100644 ---
> > > > a/drivers/power/regulator/regulator_common.c +++
> > > > b/drivers/power/regulator/regulator_common.c @@ -17,6 +17,8 @@ int
> > > > regulator_common_ofdata_to_platdata(struct udevice *dev, 
> > > >  	if (!dev_read_bool(dev, "enable-active-high"))
> > > >  		flags |= GPIOD_ACTIVE_LOW;
> > > > +	if (dev_read_bool(dev, "regulator-boot-on"))
> > > > +		flags |= GPIOD_IS_OUT_ACTIVE;
> > > >  
> > > >  	/* Get optional enable GPIO desc */
> > > >  	gpio = &dev_pdata->gpio;  
> > > 
> > > Sorry, but this is a simple revert of my commit and breaks use cases
> > > described in the commit message of this fix.  
> > 
> > No, it isn't a simple revert, and I don't think it will break the i.MX
> > ethernet driver.
> 
> I need to check this - as this issue was critical for i.MX53 (it caused
> the board not being able to update U-Boot after this change).
> 
> > 
> > I think the analysis in the commit message is a bit flawed.  I don't
> > think there was something actually wrong with commit e8e9715df2d4
> > because at the time regulator_pre_probe() was called before
> > regulator_common_ofdata_to_platdata().
> > 
> > This was changed in 29f7d05a347ab ("dm: core: Move
> > ofdata_to_platdata() call earlier"), which was the commit git bisect
> > led me to.  After that commit the boot_on member no longer being set.
> > 
> > My diff is indeed mostly a revert of yours, but it replaces the
> > boot_on member check with an explicit check of the "boot-on" property.
> > As a result the GPIOD_IS_OUT_ACTIVE flag is set correctly and the
> > regulator should be turned on (or stay on in my case).
> 
> I must have overlooked the difference. In my case the regulator had to
> be powered up early (in the preprobe) so ETH initialization would be
> performed with enabled power.
> 
> > 
> > > Do you see some kind of "glitch" on the gpio in
> > > regulator_common_of_platdata?  
> > 
> > I don't have the tools to actually measure the pin but yes all the
> > evidence points to a glitch.  I also instrumented the actual gpio
> > driver and it defenitely is setting the pin low (0) and setting it
> > high (1) again later.  So I think it is essential that
> > GPIOD_IS_OUT_ACTIVE is set when the gpio is set in the
> > gpio_request_by_name() call.  Enabling it later later isn't good
> > enough.
> > 
> > What I'm seeing on my hardware is that the NVMe device is still
> > present on the PCIe bus, but reports a bogus size and a different
> > firmware version string.  I'm fairly certain that a glitch on the 3.3V
> > pin is interrupting the load of the firmware that is stored on the
> > card itself.  When this happens, the only thing that fixes it is a
> > complete power cycle of the board.
> > 
> > > The regulator-boot-on property [1] shall prevent from the issue you
> > > described in the commit message of this revert.
> > > 
> > > Links:
> > > [1] -
> > > https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/regulator/regulator.yaml#L40
> > > 
> > > Best regards,
> > > 
> > > Lukasz Majewski
> > > 
> > > --
> > > 
> > > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > > lukma at denx.de  
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
> 
> [2:application/pgp-signature Show Save:noname (488B)]
> 

[PATCH] regulator: fix: enable gpio when requested

[Tom Rini]

On Mon, Apr 27, 2020 at 11:09:47AM +0200, Mark Kettenis wrote:

> The fix in commit b7adcdd073c0 has the side-effect that the regulator
> will be disabled when requesting the relevant gpio in
> regulator_common_ofdata_to_platdata() and enabled in
> regulator_pre_probe() when the regulator was already enabled.
> This leads to a short interruption in the 3.3V power to the PCIe
> slot on the firefly-rk3399 which makes an ADATA SX8000NP NVMe SSD
> unhappy.
> 
> Fix this by setting the GPIOD_IS_OUT_ACTIVE flag again when the
> 'regulator-boot-on' property is set, but check for this property
> explicitly instead of relying on the "boot_on" member of
> the uclass platdata.
> 
> Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
> Tested-by: Patrice Chotard <patrice.chotard@st.com>

So, before this patch, my i.MX6D cuboxi platform with FEC ethernet does
not work (dhcp never gets an IP) nor does it work after this patch, and
I'm going to bisect things as it did work as of commit d8a3f5259a36
("Merge tag 'u-boot-imx-20200107' of
https://gitlab.denx.de/u-boot/custodians/u-boot-imx").  As Lukasz's
concern is that this will break things like FEC ethernet, I believe what
I see is enough datapoints to say that the area in question needs more
investigation.  A follow-up patch from someone that tests multiple
platforms where we know we have seen oddities (firefly-rk3399, whatever
i.MX platform Lukasz was using, cuboxi) seems needed.  With that said:

Applied to u-boot/master now as it fixes some known issues and is
suspected but not confirmed to not break what b7adcdd073c0 was
addressing.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200616/8c7bfc6f/attachment.sig>

[PATCH] regulator: fix: enable gpio when requested

[Mark Kettenis]

> Date: Tue, 16 Jun 2020 09:18:35 -0400
> From: Tom Rini <trini@konsulko.com>
> 
> On Mon, Apr 27, 2020 at 11:09:47AM +0200, Mark Kettenis wrote:
> 
> > The fix in commit b7adcdd073c0 has the side-effect that the regulator
> > will be disabled when requesting the relevant gpio in
> > regulator_common_ofdata_to_platdata() and enabled in
> > regulator_pre_probe() when the regulator was already enabled.
> > This leads to a short interruption in the 3.3V power to the PCIe
> > slot on the firefly-rk3399 which makes an ADATA SX8000NP NVMe SSD
> > unhappy.
> > 
> > Fix this by setting the GPIOD_IS_OUT_ACTIVE flag again when the
> > 'regulator-boot-on' property is set, but check for this property
> > explicitly instead of relying on the "boot_on" member of
> > the uclass platdata.
> > 
> > Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
> > Tested-by: Patrice Chotard <patrice.chotard@st.com>
> 
> So, before this patch, my i.MX6D cuboxi platform with FEC ethernet does
> not work (dhcp never gets an IP) nor does it work after this patch, and
> I'm going to bisect things as it did work as of commit d8a3f5259a36
> ("Merge tag 'u-boot-imx-20200107' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-imx").  As Lukasz's
> concern is that this will break things like FEC ethernet, I believe what
> I see is enough datapoints to say that the area in question needs more
> investigation.  A follow-up patch from someone that tests multiple
> platforms where we know we have seen oddities (firefly-rk3399, whatever
> i.MX platform Lukasz was using, cuboxi) seems needed.  With that said:
> 
> Applied to u-boot/master now as it fixes some known issues and is
> suspected but not confirmed to not break what b7adcdd073c0 was
> addressing.

Thaks Tom,

It's good to have this fix in 2020.7 since we now have NVMe support on
RK3399 and the bug fixed by this commit affected many NVMe drivers.

Mark