[PATCH] regulator: fix: enable gpio when requested

Mark Kettenis
2020-06-17T16:34:21Z

> 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