linux-kernel - Re: [PATCH] regulator: core: Keep boot

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: <20120425080226.GA3195@opensource.wolfsonmicro.com>
Date:	Wed, 25 Apr 2012 09:02:27 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Ulf Hansson <ulf.hansson@...ricsson.com>
Cc:	Liam Girdwood <lrg@...mlogic.co.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mattias WALLIN <mattias.wallin@...ricsson.com>,
	Jonas ABERG <jonas.aberg@...ricsson.com>,
	Lee Jones <lee.jones@...aro.org>
Subject: Re: [PATCH] regulator: core: Keep boot_on regulators powered during
 init

On Tue, Apr 24, 2012 at 02:43:20PM +0200, Ulf Hansson wrote:

> So if grabbing a reference, there is no good point in the code were
> I can drop it. Moreover _every_ host driver needs to handle this. It
> will likely become a "hack" is my first impression.

If it's something that every host driver needs to do then just factor it
into the framework and we're done...  The stuff you're trying to put in
the regulator API feels equally like it's a bodge and it seems to me
like we've just not thought of the best way for the MMC stack to figure
out and keep track of if it needs a regulator or not.

> >This just seems awfully fragile and very much dependant on things like
> >having the driver actually enabled to clean up later.

> Setting this constraint is not done be "default", it could be
> clearly be stated that the consumer must handle the enable/disable,
> otherwise the regulator will be left in the state it was when the
> kernel booted.

Right, but the whole point in having full constraints is to avoid that.
Users are supposed to set constraints to grant permissions for things,
not to work around internal problems in the rest of the stack.  If I
could see a general use case for the feature...  but I'm having trouble
doing that.

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