Re: [RFC] shared regulator initialization and protection

[Mark Brown]

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.

Attachment: signature.asc
Description: PGP signature