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: <20120425095819.GG3195@opensource.wolfsonmicro.com>
Date:	Wed, 25 Apr 2012 10:58:19 +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>,
	Jassi Brar <jassisinghbrar@...il.com>
Subject: Re: [PATCH] regulator: core: Keep boot_on regulators powered during
 init

On Wed, Apr 25, 2012 at 11:37:36AM +0200, Ulf Hansson wrote:

> Maybe you have convinced me now :-) I will therefore start thinking
> of a patch on the mmc framework instead. I will include you if/when
> I send out the patch to the mmc-list, just for reference if that is
> ok with you?

Yes, please - there've been some issues with the way regulators are used
in MMC for a while.  There's definitely some stuff that needs to be
worked through here.

I've also added Jassi who it just occurred to me was talking about some
vaugley similar stuff relatively recently (though I'm not sure it was
MMC).  Jassi, the issue here is working out if an MMC device is powered
at boot so we can skip probing then shutting it down cleanly.

> Some final thoughts (please comment if you like):
> We already have the boot_on constraint, which to me is similar to
> what a new kind of "boot keep state" constraint would be. I think it
> would be no more odd than what boot_on already is. Maybe not a good
> argument, but still..

Yeah, the main use case for boot_on is to support things like automatic
enumeration of devices - for buses where we can enumerate devices when
they're plugged in we normally don't explicitly register them so if we
boot with the regulator disabled we need some way of allowing the device
to appear on the bus.  Don't know that that actually gets much use
though.  It is also used by regulators which for some reason can't
figure out their initial state, there's a few examples of that in
mainline.

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