Re: System will not suspend with highest numbered CPU offline [REGRESSION][BISECTED]

[Viresh Kumar <viresh.kumar@linaro.org>]

On 07-09-15, 15:32, Rafael J. Wysocki wrote:
> First, if policy->cpu is offline, the policy will be inactive to my eyes, so
> we don't need the second check.

Hmm, or maybe just drop the first check.

> But if the policy is active (and policy->cpu is online), it will not generally
> fail for an offline CPU.

Right.

> So, if the policy applies to more than 1 CPU, you
> can use any of them to manipulate it, even if one of them is offline as long
> as there are any online CPUs in the set.

Right.

> This isn't entirely consistent.  We should either fail store() for any offline
> CPU

At that point we have no idea of the CPU for which the sysfs operation
is called. And so we have to go ahead without failing, if policy is
active.

> or make the changes for offline CPUs to.

What does that mean? Most of the stuff we do is for the policy, rather
than per-cpu. And if there is per-cpu stuff, then we *only* should be
doing that for the online ones.

Not sure if I understood what you meant here. :(

> And in the particular case of
> the governor, I'm wondering what will be the problem with changing last_governor
> for an inactive policy?

I don't think we should be adding special cases for updating sysfs
attributes of an inactive policy. Its not just about the last_governor
thing, but other sysfs attributes as well.

-- 
viresh