[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140827194411.GU17528@sirena.org.uk>
Date: Wed, 27 Aug 2014 20:44:11 +0100
From: Mark Brown <broonie@...nel.org>
To: Tomasz Figa <tomasz.figa@...il.com>
Cc: Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
Doug Anderson <dianders@...omium.org>,
Olof Johansson <olof@...om.net>,
Yuvaraj Kumar C D <yuvaraj.cd@...il.com>,
linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] regulator: max77802: set opmode to normal if off is
read from hw
On Wed, Aug 27, 2014 at 09:21:02PM +0200, Tomasz Figa wrote:
> On 27.08.2014 21:15, Mark Brown wrote:
> > This is in the scenario where the previously running Linux changed the
> > mode to something other than normal and where the freshly booted Linux
> > can't figure out how to do that when it needs to. I'm not sure how
> > plausible that scenario is, or that real systems would handle it
> > robustly.
> I'm not sure I'm getting your point.
> If the only thing Linux can do is read back the opmode from PMIC
> registers, it doesn't explicitly set it to something other, but rather
> reuses what was set by something before it (or, after this patch,
> defaults to NORMAL if it's OFF), i.e. the low level firmware or Linux.
> However the information about original setting is lost whenever Linux
> turns the regulator off and performs a warm reboot, which I believe
> would be a quite common scenario.
The point is that if anything was setting the mode to something other
than normal it was almost certainly a previously running copy of Linux
and one would expect that if the mode does need to be changed the new
copy will be doing that anyway. It's rare enough to need to actively
manage modes in the first place.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists