linux-kernel - [RFC] shared regulator initialization and protection

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>] [day] [month] [year] [list]

Message-Id: <E8B060F7-567C-4659-852E-EF20628D77D1@linaro.org>
Date:	Tue, 12 Apr 2016 10:54:38 +0800
From:	Pingbo Wen <pingbo.wen@...aro.org>
To:	linux-kernel@...r.kernel.org
Cc:	Pingbo Wen <pingbo.wen@...aro.org>, lgirdwood@...il.com,
	Mark Brown <broonie@...nel.org>,
	Serge Broslavsky <serge.broslavsky@...aro.org>,
	Vincent Guittot <vincent.guittot@...aro.org>
Subject: [RFC] shared regulator initialization and protection

(Resend, previous one rejected due to html link code)

Hi,

Those day, I get some fuzz idea in a proxy-consumer regulator driver [1] from Qcom kernel tree.
The driver is simple, that let some critical regulator, which specified in DT tree, initializing 
in a pre-defined state, and hold a regulator consumer during system boot, to provide some 
protection between multi-consumers.

And I think this driver is a hint that our upstream code lack of some regulator initialization protection.
We already have some regulator flags liked always_on, boot_on in the upstream code. The boot_on 
flag can do the enable work in boot time, the regulator_get_exclusive can provide some protection
from other consumers, and the regulator consumers itself will filter out some illegal and duplicated
operation.

If a regulator only used by one consumer, current code will work fine. But for the regulator which
shared between multi-consumers, we can not make sure that the regulator will work in a defined-state,
during system boot, since the device driver can probe in any order, and set some conflict attributes.

Currently, I didn’t have much solution for this problem, but I’m work on that. The simplest solution is
to create an agent regulator driver to do the first ‘regulator_get’, just like Qcom proxy consumer driver.
Or we define a master device of a regulator, only the master device can set the regulator attributes,
other device can only do the enable operation.

Any idea?

(Hope I have cc-ed the people right)

Pingbo

- [1]  https://codeaurora.org/cgit/quic/la/kernel/msm-3.18/tree/drivers/regulator/proxy-consumer.c?h=rel/msm-3.18