From: Doug Anderson <dianders@chromium.org>
To: Mark Brown <broonie@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Evan Green <evgreen@chromium.org>,
Stephen Boyd <swboyd@chromium.org>,
digetx@gmail.com, ryandcase@chromium.org,
David Collins <collinsd@codeaurora.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force_disable()
Date: Tue, 20 Nov 2018 08:04:57 -0800 [thread overview]
Message-ID: <CAD=FV=UHiwjt2a8GFZKG3ZrRfjTgQDWD_mZu_qZP7Ve-HNTMYg@mail.gmail.com> (raw)
In-Reply-To: <20181120155458.GG3894@sirena.org.uk>
Hi,
On Tue, Nov 20, 2018 at 7:55 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, Nov 19, 2018 at 04:26:54PM -0800, Douglas Anderson wrote:
> > In regulator_force_disable() there was a strange loop that looked like:
> >
> > while (rdev->open_count--)
> > regulator_disable(rdev->supply);
> >
> > I'm not totally sure what the goal was for this loop, but it seems
> > wrong to me. If anything I think maybe we should have been looping
> > over our use_count, but even that might be a little strange. For now
> > let's just remove the code and we can add something back in if someone
> > can explain what's expected.
>
> This should be using use_count, what that loop is doing is dropping all
> the enables that the regulator being force disabled had propagated up
> all the enables it passed up the chain of supplies.
OK, that makes much more sense then. I can adjust it to do that.
I'll wait to see what happens with the rest of the patches in this
series and then post up a v2 of this one. The number of disables
needed depends on how many of the patches in my series you like. ;-)
In general it's hard for me to reason about how the system in general
should behave after regulator_force_disable() is called. Is it
basically expected that the system will panic soon after?
Specifically other consumers of the same regulator will think it's on
but it won't actually be on. What should happen if one of those other
consumers calls disable/enable? Should the regulator turn back on?
...or is the regulator permanently off until the system reboots?
-Doug
next prev parent reply other threads:[~2018-11-20 16:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-20 0:26 [PATCH 1/7] regulator: core: Properly expose requested_microamps in sysfs Douglas Anderson
2018-11-20 0:26 ` [PATCH 2/7] regulator: core: Don't assume always_on when is_enabled returns err Douglas Anderson
2018-11-20 16:00 ` Mark Brown
2018-11-20 18:17 ` Doug Anderson
2018-11-20 0:26 ` [PATCH 3/7] regulator: core: Don't double-disable supplies in regulator_disable_deferred() Douglas Anderson
2018-11-20 0:45 ` Dmitry Osipenko
2018-11-20 0:26 ` [PATCH 4/7] regulator: core: Only count load for enabled consumers Douglas Anderson
2018-11-20 0:26 ` [PATCH 5/7] regulator: core: add enable_count for consumers to debug fs Douglas Anderson
2018-11-20 16:10 ` Mark Brown
2018-11-20 16:52 ` Doug Anderson
2018-11-20 16:58 ` Mark Brown
2018-11-20 17:05 ` Doug Anderson
2018-11-20 17:57 ` Doug Anderson
2018-11-20 0:26 ` [PATCH 6/7] regulator: core: Avoid propagating to supplies when possible Douglas Anderson
2018-11-20 0:26 ` [PATCH 7/7] regulator: core: Remove loop disabling supplies in regulator_force_disable() Douglas Anderson
2018-11-20 0:58 ` Dmitry Osipenko
2018-11-20 2:05 ` Doug Anderson
2018-11-20 15:54 ` Mark Brown
2018-11-20 16:04 ` Doug Anderson [this message]
2018-11-20 16:25 ` Mark Brown
2018-11-20 16:57 ` Doug Anderson
2018-11-20 16:59 ` Mark Brown
2018-11-20 17:00 ` Mark Brown
2018-11-20 17:55 ` Doug Anderson
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='CAD=FV=UHiwjt2a8GFZKG3ZrRfjTgQDWD_mZu_qZP7Ve-HNTMYg@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=bjorn.andersson@linaro.org \
--cc=broonie@kernel.org \
--cc=collinsd@codeaurora.org \
--cc=digetx@gmail.com \
--cc=evgreen@chromium.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ryandcase@chromium.org \
--cc=swboyd@chromium.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).