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]

Date:	Mon, 14 Jan 2013 01:42:40 +0000
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 Sun, Jan 13, 2013 at 11:35:03PM +0000, Kim, Milo wrote:

> Thanks for your opinion.
> My understanding is 'shared' enable pin means regulators are enabled/disabled
> at the same time.
> Any other case is possible?

So, clearly that's going to be the behaviour at the system level but the
consumers aren't going to know that.  If the consumer supports some of
the supplies being enabled and disabled separately then it will rely on
the regulator core reference counting to keep the supply enabled if
there are other reasons to do so.  This is how things would work if both
supplies came from the same regulator so I'd expect us to preserve the
same behaviour.
--
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/