[PATCH v3 3/3] arm: kernel: implement cpuidle_ops with psci backend

[lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)]

On Mon, Jul 27, 2015 at 10:45:07AM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 27, 2015 at 10:16:02AM +0100, Lorenzo Pieralisi wrote:
> > Yes, I would only ask you, if the plan above (which can be implemented
> > in two steps) makes sense to you please consider accepting Mark's change
> > to consolidate PSCI code into drivers/firmware/psci, it is a stepping stone
> > without which the changes above can't happen, I will take charge of completing
> > the move of CPUidle code and create the required shim layer into
> > drivers to make this happen.
> 
> Why can't Jisheng Zhang base his patches on top of Mark's changes and
> place the new file directly under drivers/ ?
> 
> Why do it as a two-step process with it first appearing in arch/arm,
> and then having to generate another patch at a later date to move it
> elsewhere.  That just creates more noise, and we should be avoiding
> generating noise in arch/arm.

Nothing will appear in arch/arm, I promise, I said two-step process
because Mark's series is standalone/ready-to-be-merged while Jisheng
patch series has still some bits to be debated (that won't affect
what we discussed in relation to the code split and do not require
any change in Mark's series at all).

No code move, nothing in arch/arm, we will stick to the plan as I said
before and I fully agree with that, please do not block one mature patch
series for another one that still has some bits to be settled, and they
are totally independent.

> This is what Linus has said in his -rc4 release notes yesterday:
> 
>    Other than that issue, it's mostly drivers and networking.  USB, gpu,
>    mmc, network drivers, sound. With some ARM noise (but even that is
>    mostly driver-related: dts updates due to MMC fixes). And a few small
>    filesystem fixes.
> 
> and we can infer from the phrase "ARM noise" that Linus' opinion of
> arch/arm is still fairly low, and still doesn't regard the "churn" in
> arch/arm as being useful.

Mark's series consolidate ARM/ARM64 PSCI implementations, it does not
require creating anything in arch/arm actually it moves code in arch/arm
to drivers/firmware, consolidating it, it is definitely the right
thing to do in this respect.

The CPUidle code comes as a second series on top of Mark's one and it
will _not_ add anything in arch/arm (if you allow Mark to proceed), you
have my word :)

Does it sound ok to you ?

Thanks !
Lorenzo