Hi, Russell,

On Sat, 2 Jan 2016, Russell King - ARM Linux wrote:

quoted

On Tue, Dec 29, 2015 at 02:54:10PM +0100, Thomas Gleixner wrote:

quoted

I have no real opinion about that patch. It does no harm to
unconditionally setup the hrtimer based broadcast even if it's never

used.

quoted

quoted

Up to the arch maintainer to decide.

That's really not fair to keep shovelling these kinds of decisions
onto architecture maintainers without any kind of explanation about
how an architecture maintainer should make such a decision.

Do I roll a 6-face dice, and if it gives an odd number, I apply this
patch, otherwise I reject it?

Is there a technical basis for making the decision?  If so, please
explain what the technical arguments are against having or not having
this change.

The hrtimer based broadcast device is used when you have per cpu timers
which stop in deeper power states, but you have no other timer hardware on
the chip which can backup the per cpu timer in deep power states. The
trick is that it emulates a timer hardware via a hrtimer and then tells
the cpu idle code not to go into deep power states on the cpu which owns
that hrtimer. All other cpus can go as deep as they want and still get
woken up.

The only downside of adding this unconditionally is extra code in case
that it is not needed on a particular platform.

Hope that helps.

[Alison Wang] What's your opinion about this explanation? Is this patch acceptable?

Best Regards,
Alison Wang