linux-kernel - Re: [patch 2.6.29-rc7 regulator-next] regulator: init fixes

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: <200903142116.03901.david-b@pacbell.net>
Date:	Sat, 14 Mar 2009 21:16:03 -0700
From:	David Brownell <david-b@...bell.net>
To:	Mark Brown <broonie@...ena.org.uk>
Cc:	Liam Girdwood <lrg@...mlogic.co.uk>,
	lkml <linux-kernel@...r.kernel.org>,
	OMAP <linux-omap@...r.kernel.org>
Subject: Re: [patch 2.6.29-rc7 regulator-next] regulator: init fixes

On Thursday 12 March 2009, Mark Brown wrote:
> On Wed, Mar 11, 2009 at 06:32:15PM -0800, David Brownell wrote:
> 
> > Make the regulator setup code cope more consistently with
> > regulators undesirably left enabled by the bootloader.
> 
> First up I'd just like to make it absolutely clear that I agree that
> this is a feature we should have - it's obviously useful.

Feature being "consistency".  I'd say "essential", not
merely "useful" ... this is bugfix territory.

There are things that just can't work with the current
regulator framework, because its handling of this routine
scenario is so inconsistent.  It's not necessarily going
to be safe to force every (!!) driver into that dance you
had described (enable-it-then-disable-it), just to force
all regulators into the kind of self-consistent state that
framework users always expect to start with.

Especially:  RIGHT AFTER INITIALIZATION!!!  There's no
excluse to be self-inconsistent that early, even if
there were an excuse later on.

The "v4" patch I posted resolves that inconsistency in
about the simplest way I can find; but unlike this patch
it doesn't solve the "force this regulator off" problem.

> It is a particular problem for multi-function devices like pcf50633
> which not only register all their regulators by default but also embed
> constraints within the general pcf50633 platform data.

The pcf50633 driver didn't *need* to register all regulators;
and I don't see what the issue would be with platform_data.
Its MFD core could easily check the regulator init data and
skip regulators that didn't initialize a key field.

> If the user 
> simply turns on the regulator driver in their config they'll get this
> behavior if they don't edit the code.  Even with regulator code I'd not
> be surprised if people were bitten by this for things like the memory or
> a CPU core without regulator based DVFS.

That would be part of why the twl4030 regulators are only
registered on request!  Not only will a given board tend to
not use all those regulators, but a number of them really
aren't intended to be managed by Linux.  (And then there
are board options, like what various control signals do.)

Similar things could happen with a system using pcf50633.
There's no reason one of the LDOs or switching regulators
shouldn't be managed exclusively by another I2C master on
that bus ... they each have dedicated registers, and its
not uncommon to dedicate a microcontroller to managing just
one part of a system (and its resources).

> You've addressed some of the use cases for this by providing devmode but

I think it's pretty ugly myself, but you did say something about
wanting explicit support for reverse engineering.  The "v4" patch
which I just sent uses a simpler approach; such support doesn't
need to be explicit in order to work.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/