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]
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)

Powered by blists - more mailing lists