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: <20160615133255.GZ2282@sirena.org.uk>
Date:	Wed, 15 Jun 2016 14:32:55 +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 Wed, Jun 15, 2016 at 08:05:13PM +0800, Pingbo Wen wrote:
> On Thursday, June 09, 2016 01:16 AM, Mark Brown wrote:

> > It doesn't, it postpones them until late_initacall().  This is both
> > after the consumers have loaded if they are built in and before any
> > consumers built as modules come up.

> Yes, this patch only protects a regulator from regulator
> registration(built in) to late_initcall(). But, IMO, if a regulator is
> critical, it's weird to build as a module. Maybe I was thoughtless here.

Well, this comes back to the issue with it being very use case specific
and not generally clear what critical regualtors are supposed to be.  It
really depends on what the system integrator wants, and there's things
like the distro use case where the normal thing to do is to build as
many drivers as possible as modules since you support such a huge range
of hardware.

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

> Any idea?

There were the other ideas I mentioned in my mail too.

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