linux-kernel - Re: [PATCH] regulator: arizona-ldo1: Only enable status change if we have LDOENA

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: <20160424232305.GK3217@sirena.org.uk>
Date:	Mon, 25 Apr 2016 00:23:05 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Richard Fitzgerald <rf@...nsource.wolfsonmicro.com>
Cc:	lgirdwood@...il.com, patches@...nsource.wolfsonmicro.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: arizona-ldo1: Only enable status change if we
 have LDOENA

On Fri, Apr 22, 2016 at 05:38:02PM +0100, Richard Fitzgerald wrote:

Please fix your mailer to leave blank lines between paragraphs (and not
delete them in quotes), it makes your mails harder to read.

> On 22/04/16 16:04, Mark Brown wrote:
> >On Fri, Apr 22, 2016 at 02:43:28PM +0100, Richard Fitzgerald wrote:

> >What's the difference between this and the previous version of the patch
> >and what problem is this aiming to solve?  If we want to disable the
> >regulator why would we not be happy to do that by removing the supply?

> The background to all this is that runtime suspend and resume needs to know
> whether the DCVDD turned off. If it definitely turned off a regmap cache
> sync is safe - if not or I can't be sure then I need the overhead of a
> forced reset to restore register defaults before the sync.

This is what regulator status change notifiers are for, register and
then you'll get a callback when the power is actually pulled (there's a
few other CODEC drivers that use them).

> What I'm trying to achieve here is to stop the regulator core sending false
> notifications that LDO1 has been turned off. The way that the regulator core

If you've found a problem with spurious notifications then fix the
spurious notifications, don't pile bodges into consumer drivers!  Every
single other driver that relies on these notifications is going to want
the same hack for the same reason though most of them aren't their own
supply so won't be able to do it.  The advantage of being able to change
the source code for the entire kernel is that we don't need to have
workarounds for the core in drivers, we can make the core do the right
thing.

> code handles the disable notifier has no dependency on what happens to the
> parent supply. The REGULATOR_CHANGE_STATUS flag is used to indicate whether
> the status of _this_ regulator can be changed (it doesn't affect whether the
> parent is disabled).

If the child can't change status then the disable can't propagate up the
tree and the child regulator needs to hold the parent enabled.

> I think it's a bug that LDO1 claimed to be able to turn off when it couldn't,
> and fixing that prevents bogus disable notifications.

How does the driver know it couldn't turn off the parent, it knows
nothing about the supply for LDO1?  If that's switchable you've just
removed the ability to switch it off since the rail will now never power
down.

Regulators with no enable control of their own need to not do their own
notifications but instead get notifications based on parent status
changes.

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