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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1245996263.10360.122.camel@brutus>
Date:	Fri, 26 Jun 2009 03:04:23 -0300
From:	Daniel Ribeiro <drwyrm@...il.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.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).

Em Sex, 2009-06-26 às 00:37 +0100, Mark Brown escreveu:
> On Thu, Jun 25, 2009 at 05:29:53PM -0300, Daniel Ribeiro wrote:
> > +	/*
> > +	 * The regulator framework doesn't like regulators which default
> > +	 * to ON at boot time, so we just disable it here (when it is safe).
> > +	 */
> > +	if (pdev->id == VAUX2 || pdev->id == VAUX3)
> > +		pcap_regulator_disable(rdev);
> 
> No need to do this - the regulator framework is perfectly happy with
> regulators that are enabled at boot time and turning regulators that are
> 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.

Humm, I still see:

        if (WARN(rdev->use_count <= 0,
                        "unbalanced disables for %s\n",
                        rdev->desc->name))
                return -EIO;

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
regulator probe(). VAUX2 and VAUX3 are only used for MMC on all the
hardware that I know of, so it is safe.

Also, on regulator_init_complete() the regulator core disables all
regulators which have a use_count == 0. So, its kind of funny that if I
don't disable the regulator at boot(so mmc_core does enable() it), the
timing causes regulator_init_complete() to auto-disable the regulator
right when pxamci.c is probing the card.

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:

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.

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

-- 
Daniel Ribeiro

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