Re: Unable to boot mainline on snow chromebook since 3.15

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]

On Wed, Sep 10, 2014 at 05:29:32PM +0100, Grant Likely wrote:

> What we can do is have an inhibit flag for
> simplefb/simpleuart/simplewhatever that holds off PM. When a real
> driver, or a stub that understands parsing the resource dependencies,
> takes ownership of the device (or userspace tells the kernel to stop
> caring) it can clear the inhibit.

It's not quite as simple as just disabling PM - for example in the
clocks case we've also got to worry about what happens with rate changes
(which is going to get more and more risky as we get smarter about being
able to push configuration changes back up the tree), regulators have a
similar thing with voltage changes.  With simple enables and disables we
have to worry about things like handling users who actively want to
power things on and and off but may potentially be sharing a resource
with an undeclared dependency.

If we are going to go with an approach like you suggest I think that
rather than require a userspace notification that everything is OK we
should have the stub drivers do something which causes the appropriate
behaviour to happen so long as they're loaded.  This means userspace
doesn't need an update and ensures it doesn't have to worry about cases
where we're using the stub driver at runtime due to a real driver not
being available - we can figure this stuff out within the kernel
oureslves.

That said a kick from userspace when the first round of module loading
has finished would be very helpful, I just don't think we should rely on
it for this behaviour.

> I don't want to build knowledge of resource dependencies into the
> simple case. We'll simply frequently get it wrong. For example: A
> future kernel will have better PM and will turn off more devices which
> isn't accounted for in an older DT.

That is tricky and there will be problems.  Being fairly aggressive
about doing these things and avoiding having runtime configuration hacks
since it makes it harder for people to introduce problems without
noticing them, and requiring an explicit request to do resource
management at all is the most conservative option.  Between them those
strategies should help for anything that's getting tested at least, it
makes it hard for the kernel to learn about a resource without it being
handled safely from the get go.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]