linux-kernel - Re: [PATCH 2/3] regulator-core: update all enable GPIO state in

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: <20130113224220.GE5041@opensource.wolfsonmicro.com>
Date:	Mon, 14 Jan 2013 07:42:21 +0900
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	"Kim, Milo" <Milo.Kim@...com>
Cc:	Axel Lin <axel.lin@...ics.com>, "Girdwood, Liam" <lrg@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] regulator-core: update all enable GPIO state in
 _enable/disable

On Thu, Jan 10, 2013 at 09:46:12AM +0000, Kim, Milo wrote:

> +	/* Update shared enable pin state */
> +	list_for_each_entry(r, &regulator_list, list) {
> +		if (r->ena_gpio == gpio)
> +			r->ena_gpio_state = enable ? 1 : 0;
> +	}
> +}

This isn't quite going to work properly - we need to actually move the
state (and also a reference count) into some sort of shared state.
Otherwise consider what happens in this scenario:

	1. regulator 1 enables
	2. regulator 2 enables
	3. regulator 1 disables

Since regulator 1 doesn't know anything about regulator 2 it'll not know
that regulator 2 should still be enabled so it'll put the GPIO into the
disabled state.  It'll be OK if regulator 1 and regulator 2 always have
the same state but if they ever differ then we'll not do the right thing.

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