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: <20090626105550.GE5415@sirena.org.uk>
Date:	Fri, 26 Jun 2009 11:55: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 03:04:23AM -0300, Daniel Ribeiro wrote:
> Em Sex, 2009-06-26 às 00:37 +0100, Mark Brown escreveu:

> > actively being used off is likely to cause issues.  Regulator drivers
> > should just leave everything as they find it and leave it up to the core
> > and machine drivers to make any changes.

> So, the regulator is enabled at boot, but it can't be disabled because
> use_count is 0. This is the same issue as twl4030-mmc, but instead of a
> enable/disable pair on pxamci.c i opted to disable it at pcap's

At the minute you need to use the enable/disable pair since (as we've
previously discussed) the API needs to support regulators which are
shared between multiple users (potentially including multiple users from
the same consumer).

> regulator probe(). VAUX2 and VAUX3 are only used for MMC on all the
> hardware that I know of, so it is safe.

I've heard that one before :)

> I can move this hack to pxamci.c if you want me to (as David did for
> twl4030), but this issue really should be fixed on regulator/core.c:

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.

> With the current code if you use a regulator which can be disabled as
> the supplier for the CPU core, then the regulator framework will power
> off the CPU at boot.

This will only be done if the board has said that it has fully specified
the regulator configuration - if the board hasn't done that then the
state of the regulators will stay unchanged.  The regulator API is very
dependant on boards supplying good constraints, if bad constraints are
provided the consequences could include even more serious things like
lasting hardware damage.  This is just an example of what can go wrong
with a bad board setup.

> Maybe you should simply allow disable() if use_count is 0, and not
> auto-disable() on regulator_init_complete() ?

That doesn't fulfil the same need since it requires that there be a
consumer for the regulator to actively sit there and disable it.  It's
not intended to help if a consumer actively needs to have the regulator
disabled right now, it's there to disable the regulator if nothing wants
to have it on which isn't quite the same thing.
--
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/