[PATCH] regulator: fix: enable gpio when requested

Tom Rini trini at konsulko.com
Tue Jun 16 15:18:35 CEST 2020


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 at openbsd.org>
> Tested-by: Patrice Chotard <patrice.chotard at 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>


More information about the U-Boot mailing list