linux-kernel - Re: [PATCH] regulator: Provide a check for dummy regulator

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: <20120420144256.GA6828@opensource.wolfsonmicro.com>
Date:	Fri, 20 Apr 2012 15:42:57 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Jassi Brar <jaswinder.singh@...aro.org>
Cc:	linux-kernel@...r.kernel.org, lrg@...com
Subject: Re: [PATCH] regulator: Provide a check for dummy regulator

On Fri, Apr 20, 2012 at 07:18:15PM +0530, Jassi Brar wrote:
> On 20 April 2012 18:31, Mark Brown <broonie@...nsource.wolfsonmicro.com> wrote:

> > No.  You're failing to understand what dummy regulators are for.

> I think I do understand what dummy regulators are for and also that
> they are meant to go away some time in future.

No, they're here to stay - people will always be bringing up new boards
after all - but they're not supposed to be used on platforms.

> >  To repeat yet again you're not supposed to actually use dummy regulators,
> > you're supposed to fully specify the regulators on your platform.

> I use dummy regulators for what they are meant for - until every platform
> completely define supplies for every consumer.
> We are not there yet, yet one 'ideal' consumer suffers because of that.

> If you ask me to go away and disable dummy and update all consumers
> and their platforms, then I say why not remove the concept of dummy
> altogether which only delays full compliance to the regulator api ?

The only reason dummy regulators are there is to provide a get out of
jail card to help keep systems booting when there's a problem with their
regulator setup.  Managing the introduction of regulator support to new
drivers is relatively hard, I don't see us getting it right first time
every time, so it's unlikely we'll ever be able to get rid of these
crutches.  It keeps people happy so even though the regulator setup is
generally trivial to fix when an issue crops up it's less hassle to have
the option.

In any case, as I've said it's not the fact that you've got a dummy
supply that's an issue for most of the cases you mention - it's the fact
that the supply is always on.  

Even in the case where a supply might genuinely be missing (which are
very unusual, it's more effort in silicon to cope with missing supplies)
you're still stuck with guessing if the supply is missing because of
missing regulator setup or if the supply really is not physically
present.  If you really want to try to bodge in something for thingns
like this in the consumer probably a good solution is to do something
like have the driver check that it can get a sensible voltage back
though I'd be interested to see a driver that can usefully use it and a
system which did so.  Your example seemed pretty theoretical and it'd be
more usual to tie to a supply so I'd really like to look at some
concrete systems that do this.

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