linux-kernel - Re: [PATCH] PCAP regulator driver (for 2.6.32).

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: <20090626150849.GA5504@sirena.org.uk>
Date:	Fri, 26 Jun 2009 16:08:51 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Daniel Ribeiro <drwyrm@...il.com>
Cc:	Liam Girdwood <lrg@...mlogic.co.uk>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	openezx-devel <openezx-devel@...ts.openezx.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	David Brownell <dbrownell@...rs.sourceforge.net>
Subject: Re: [PATCH] PCAP regulator driver (for 2.6.32).

On Fri, Jun 26, 2009 at 09:26:32AM -0300, Daniel Ribeiro wrote:
> Em Sex, 2009-06-26 às 11:55 +0100, Mark Brown escreveu:

> > You need to either do that or add an API allowing consumers to claim a
> > regulator for exclusive use.  If the regulator is claimed for exclusive
> > use then other consumers wouldn't be able to access it and there would
> > be no issue with interfering with other users.

> I'm not proposing an API for exclusive use. Allowing the enable bit to
> be turn off case use_count is 0 shouldn't break regulator sharing for
> other consumers, as far as the regulator framework is concerned there
> are no other consumers.

What breaks things for non-exclusive use is that the driver is doing a
disable when it didn't do the corresponding enable.  This means that if
whatever did the enable still cares about the device being enabled then
it will get upset.  The reason the regulator API complains here is to 
help catch problems in drivers rather than because it itself will fall
over.

> What about increasing use_count at regulator_get() if the regulator is
> already on and use_count == 0? If a consumer requests a regulator that
> was previously ON, then there is no reason for it to enable/disable it.
> If it is requested, and its already ON, then the regulator framework can
> assume it is already being used.

Think about the shared use case here.  If the regulator is enabled when
a consumer starts then the consumer can't tell if this was because the
regulator happened to be left on at system startup or if it was because
some other user of the regulator has enabled it.  This means that none
of the consumers can ever drop that use count so it's stuck there and
the regulator can never actually be disabled.

> If the above is not possible, then regulator_is_enabled() doesn't match
> regulator_enable()/regulator_disable() pair. Maybe the API should make
> this clear?

Frankly I'm not sure how much any documentation is going to help here.
There's already a note about the fact that the regulator might've been
enabled elsewhere, it could be strengthened a bit but it still relies on
people reading it.

Fundamentally, if your consumer is trying to explicitly force the
regulator off then it's not able to cope with the regulator being
shared.  I suspect that if someone does add a non-shared API then the
problem will go away, half the problem is with consumers thinking they
have exclusive use of the regulator.
--
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/