linux-kernel - Re: [PATCH 1/1] regulator: max77802: set opmode to normal if off is read from hw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140827210350.GD17528@sirena.org.uk>
Date:	Wed, 27 Aug 2014 22:03:50 +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 10:41:42PM +0200, Tomasz Figa wrote:
> On 27.08.2014 22:25, Mark Brown wrote:

> > Well, presumably the bootloader is going to run again even for a warm
> > reboot?

> This is strange, but apparently it's not the case for the hardware which
> this patch is supposed to fix or at least this is how I understood it.

Fun.  It's like everyone was setting out to define the most fragile
system they could, from the chip design up...  so many moving pieces
that have to line up.

> > It's not in general true that Linux should never change the mode (the
> > main case for toggling modes is usually going between an idle/suspend
> > state and active state)

> I believe this is yet another reason why we should have a way to specify
> opmodes in DT, now not only active but also suspend/idle opmodes.

> However on many PMICs this is a bit more complicated. There are opmodes
> such as

Well, quite.  Plus the more basic question of what a mode actually is
and how you talk about them generically.  It's not that there's no use
for this functionality, it's that it doesn't lend itself to defining
ABIs.

> > You're talking about the case
> > where the bootloader does set something but avoids doing so on warm
> > reboots only here.

> From Javier's description I understood this is the case for the board
> for which he develops.

No, the issue is that the bootloader isn't touching the regulator then
Linux turns it off, reboots and ends up thinking the default operating
mode is off which doesn't work terribly well when it tries to enable the
regulator.  The reading back from hardware is trying to implement the
standard Linux behaviour of not changing a setting without explicit
permission, this change is providing a fallback for the case where
that's giving us something obviously wrong.

> > Besides, even if we did have a way of specifying modes in DT (with all
> > the problems that brings) we still have to pick a default if that's not
> > used).

> Sure we do and we can define the binding to default to something (e.g.
> normal mode) if respective property is not present. Btw. the issue with
> opmode also affects other PMIC chips such as Samsung S5M ones.

That's then going against our purposely conservative implementation, and
would be especially bad if it overrode one of the hardware managed modes
on an otherwise unused regulator.

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)