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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 17 Jun 2016 12:42:35 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Pingbo Wen <pingbo.wen@...aro.org>
Cc:	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 Fri, Jun 17, 2016 at 11:34:25AM +0800, Pingbo Wen wrote:
> On Wednesday, June 15, 2016 09:32 PM, Mark Brown wrote:

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

I don't understand what this means, sorry.

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

If the driver is not initializing itself during probe the driver is
doing something wrong and needs to be fixed anyway.

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