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.