All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: u-boot@lists.denx.de
Subject: [PATCH] regulator: fix: enable gpio when requested
Date: Wed, 17 Jun 2020 18:34:21 +0200 (CEST)	[thread overview]
Message-ID: <ea270bb1319b0ec2@bloch.sibelius.xs4all.nl> (raw)
In-Reply-To: <20200616131835.GS24893@bill-the-cat> (message from Tom Rini on Tue, 16 Jun 2020 09:18:35 -0400)

> 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

      reply	other threads:[~2020-06-17 16:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27  9:09 [PATCH] regulator: fix: enable gpio when requested Mark Kettenis
2020-04-27 12:06 ` Patrice CHOTARD
2020-04-27 22:24 ` Simon Glass
2020-04-28  4:24 ` Lukasz Majewski
2020-04-28  9:23   ` Mark Kettenis
2020-04-28 18:26     ` Lukasz Majewski
2020-05-13  9:14       ` Mark Kettenis
2020-06-16 13:18 ` Tom Rini
2020-06-17 16:34   ` Mark Kettenis [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ea270bb1319b0ec2@bloch.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.