linux-kernel - Re: [PATCH 1/2] MMC/pxamci: workaround regulator framework bugs

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] [day] [month] [year] [list]

Message-ID: <20090724143547.GC28228@rakim.wolfsonmicro.main>
Date:	Fri, 24 Jul 2009 15:35:47 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	David Brownell <david-b@...bell.net>
Cc:	Eric Miao <eric.y.miao@...il.com>,
	Daniel Ribeiro <drwyrm@...il.com>,
	Pierre Ossman <pierre@...man.eu>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	openezx-devel <openezx-devel@...ts.openezx.org>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	linux-arm-kernel <linux-arm-kernel@...ts.arm.linux.org.uk>
Subject: Re: [PATCH 1/2] MMC/pxamci: workaround regulator framework bugs

On Wed, Jul 22, 2009 at 02:03:07PM -0700, David Brownell wrote:

> 	/* that this simple idiom would finally work */
> 	if (regulator_is_enabled(r))
> 		regulator_disable(r);

For the avoidance of future disappointment please note that an exclusive
access request does not remove the reference counting on the regulator,
it only changes the way in which it is intialised.  This means that the
above code is only guaranteed to cause the regulator to be disabled so
long as the consumer never calls enable() twice without a matching
disable().  It will, however, not return an error due to unbalanced
enables and disables which I believe is your primary requirement here.

> of which were within (d) an ever-increasing number of constraints
> you grew with each new iteration.  I had to try so many different
> approaches since nothing seemed to be getting through.  The lack

For clarity and in the hope that this helps to avoid future issues
let me list the three major constraints in this area:

 - The API supports shared regulators.
 - Regulator enabling by software is reference counted.
 - Changing the state of regulators before drivers have had a chance to
   take control of the devices is very disruptive to the system and
   needs to be avoided as a result.

Everything else flows from those, in conjunction with the standard
considerations about making sure that any transitions are managed in as
graceful a fashion as possible.

I'm leaving the rest of your mail because I don't think discussing that
further here is going to get us anywhere.
--
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/