linux-kernel - Re: [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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160418094624.GM3217@sirena.org.uk>
Date:	Mon, 18 Apr 2016 10:46:24 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Pingbo Wen <pingbo.wen@...aro.org>
Cc:	linux-kernel@...r.kernel.org, lgirdwood@...il.com,
	Serge Broslavsky <serge.broslavsky@...aro.org>,
	Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [RFC] shared regulator initialization and protection

On Mon, Apr 18, 2016 at 03:26:03PM +0800, Pingbo Wen wrote:
> On Tuesday, April 12, 2016 11:48 AM, Mark Brown wrote:
> > On Tue, Apr 12, 2016 at 10:44:11AM +0800, Pingbo Wen wrote:

> > What is the actual problem here?  Every driver is responsible for
> > ensuring that regulators are in a good state before it starts using the
> > hardware, if some other device did something before why do we care?

> Yes, I agree the driver should set the regulator before do the real work,
> when the device life time is started from driver probing. But if the device
> life time is started before Linux kernel loading, the regulator core should
> do the regulator initialization and protection to power the device properly,
> during kernel booting, until the consumer driver probed.

We can't guarantee that a consumer for a device will ever load in any
reasonable time.  There may be no driver, the driver may have hit some
other problem, the driver may not have been built or may have been built
but placed on inaccessible media.  It's fundamentally an unresolvable
problem outside of specific system integration, we have no way of
telling at what point to give up on something appearing.  The closest
we've got is initcalls but they are before modules get loaded so mean
things break as soon as they're built modular.

> > Anything based on doing things at initcall levels is fundamentally
> > broken, as soon as things are built modular like most things in a distro
> > kernel then it'll stop working.  If the system integrator needs some
> > devices to start early to provide continuity (the main case here is
> > display) they need to deal with that at the system integration level.

> Adding a initcall to do the consumer removing is not a decent method.
> We can do some hack in regulator_get(), removing agent consumer until
> specified device call regulator_get(), or the first regulator_get().

Then what happens if that driver never loads?  The other consumers are
stuck being unable to control the regulator indefinitely which isn't
great.

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