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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20120420184806.GA3092@opensource.wolfsonmicro.com>
Date:	Fri, 20 Apr 2012 19:48:07 +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 11:55:22PM +0530, Jassi Brar wrote:
> On 20 April 2012 20:12, Mark Brown <broonie@...nsource.wolfsonmicro.com> wrote:

> > 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.

> "some time in future" means utopia.... whenever that be. The longer that is
> to more important is it for dummy support to be 'complete'.

Well, for any given board it's very quick to resolve.  It's just that
from time to time people will break things and then they'll get annoyed
(and probably spend forever complaining on the lists rather than the
brief time taken to make the patch).

> > 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.

> I am not sure anymore you read my posts :(
> I am more bothered by the case where the supply is always off i.e,
> physically absent.

It's not what you first mentioned...  In any case, the solution is very
clear - just do proper regulator support and turn off dummy regulators
and everything is fine.

> > 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)

> It's not that unusual.  See vcc_aux at line 150 of omap_hsmmc.c

No, really - that's exceptionally unusual and quite honestly given the
"discussion" surrounding the addition of the regulator support there I'm
not convinced that anything the driver is doing here is sane; the whole
stuff with regulator_get_exclusive() never made any sense for MMC in the
first place (and has now been removed).

> See how dummy fools the driver throughout into stuff like toggling vcc
> even for platforms that don't really provide vcc_aux.
> In practice, see how dummy affects (negatively because of unnecessary
> toggles) the vcc too.  Not every platform with omap_hsmmc might afford
> having dummy disabled (I don't know all to tell for sure).

The fix here is in the boards, not with the dummy code.  Open coding
handling of this sort of stuff in individual consumers is just insane,
and you're always going to run into the situation where you don't know
if the dummy regulator is there because the board setup is incomplete or
because someone left the option turned on when it shouldn't be.

What you want here is something like regulator_get_real_no_really()
which never returns a dummy regulator but the whole thing is just adding
fragility onto bodge.  I'm not overly concerned if systems don't run as
efficiently as they might when using dummy regulators because (like I
say) they're just a crutch to keep systems running.

Note also that the performance improvement stuff I sent the other day
will help here, the bounces will be very cheap now.

I'd much rather remove the feature than start going down this rabbit
hole, it's just going to be a world of pain and fragility.  But then a
whole different bunch of people will complain.

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