linux-kernel - Re: [RFC PATCH] regulator: introduce boot protection flag

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: <57636FC1.3040607@linaro.org>
Date:	Fri, 17 Jun 2016 11:34:25 +0800
From:	Pingbo Wen <pingbo.wen@...aro.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	pingbo.wen@...aro.org, linux-kernel@...r.kernel.org,
	lgirdwood@...il.com, vincent.guittot@...aro.org,
	stephen.boyd@...aro.org
Subject: Re: [RFC PATCH] regulator: introduce boot protection flag



On Wednesday, June 15, 2016 09:32 PM, Mark Brown wrote:
> On Wed, Jun 15, 2016 at 08:05:13PM +0800, Pingbo Wen wrote:
>> On Thursday, June 09, 2016 01:16 AM, Mark Brown wrote:
>
>> If we take modules under consideration, and to make this patch more
>> universal, I think what we really need is adding a flag to protect a
>> regulator from registration to a specific consumer(not the first
>> consumer). The regulator driver gives the initial state, and the
>> specific consumer need to clear this flag while finishing regulator
>> setting(by calling a function like regulator_clear_protect()). And what
>> the regulator core need to do is staging all operations during
>> protection. And that will cover all consumers probing order, whenever
>> the regulator is registered.
> 
> Having the consumer driver know that it's "critical" seems wrong since
> different systems may have different ideas about that, it's probably
> better to hook this in with the device model so that when the device
> finishes probing that kicks things off.
> 

That will imply the protection would be end when the specific device has
probed, and consumers should take their place at the same time. But
there have some other devices, which will set the consumer in a IRQ
event, or after some other events, can't be covered.

We can set the protection flag easily, but it's hard to tell whether a
consumer is well initialized, the end of protection, since regulator
consumer is not initialized within one call.

Pingbo