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 02:44:08 +0000
From:	"Kim, Milo" <Milo.Kim@...com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.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

> From: Mark Brown [mailto:broonie@...nsource.wolfsonmicro.com]
> 
> 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.

OK, the consumer just cares about the regulator(s) which is(are) obtained.
However it doesn't show exact state of regulator in case that enable GPIOs are
shared.
For example, LDO1 and LDO3 can be enabled by same GPIO pin.
But there are two separate regulator consumers, CA and CB.

(1) CA gets LDO1 regulator.
(2) CB gets LDO3 regulator.
(3) CA enables LDO1 (the GPIO goes to HIGH state)
    : Both LDO1 and LDO3 are enabled physically.
(4) CB also enables LDO3
    : But no GPIO state is changed because GPIO is already HIGH state.
(5) CA disables LDO1. LDO3 also is turned off eventually.
(6) CB tries to get the state of LDO3 before disabling it,
regulator_is_enabled() returns 1, but real state is 0.

	if(!regulator_is_enabled(rdev))
		regulator_disable(rdev);

	Therefore CB never disables LDO3, use_count is always 1.

This patch solves this unmatched situation.

But based on regulator behavior, I don't need to care this situation either.
A regulator consumer handles their *own* regulator(s).
Regulator APIs may show unmatched value, but it can be handled in each consumer 
driver *separately*.
Therefore, we should not update 'ena_gpio_state' of other regulators.
This patch should be ignored.
Is that correct?

Best Regards,
Milo



--
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/