[PATCH 0/2] arm64: remove generic ARM cpuidle support

[Will Deacon]

On Wed, Jun 22, 2022 at 03:07:48PM +0100, Sudeep Holla wrote:
> On Wed, Jun 22, 2022 at 01:59:07PM +0200, Michael Walle wrote:
> > Am 2022-05-29 20:13, schrieb Michael Walle:
> > > Playing with an own PSCI implementation, I've noticed that the
> > > cpuidle-arm
> > > driver doesn't work on arm64. It doesn't probe because since commit
> > > 788961462f34 ("ARM: psci: cpuidle: Enable PSCI CPUidle driver") the
> > > arm_cpuidle_init() can only return -EOPNOTSUPP, because the commit
> > > removed
> > > the cpu_idle_init and cpu_suspend ops.
> > > 
> > > It left me puzzled for quite some time. It seems that the cpuidle-psci
> > > is
> > > the preferred one and this has been the case for quite some time. The
> > > mentioned commit first appeared in v5.4.
> > > 
> > > Remove the ARM64 support for the cpuidle-arm driver, which then let us
> > > remove all the supporting arch code.
> > > 
> > > Michael Walle (2):
> > >   cpuidle: cpuidle-arm: remove arm64 support
> > >   arm64: cpuidle: remove generic cpuidle support
> > > 
> > >  arch/arm64/include/asm/cpu_ops.h |  9 ---------
> > >  arch/arm64/include/asm/cpuidle.h | 15 ---------------
> > >  arch/arm64/kernel/cpuidle.c      | 29 -----------------------------
> > >  drivers/cpuidle/Kconfig.arm      |  3 ++-
> > >  4 files changed, 2 insertions(+), 54 deletions(-)
> > 
> > Through which tree should this patchset go? I've seen it is marked as
> > "Handled Elsewere" in the linux pm patchwork [1].
> > 
> 
> Generally based on the changes, it is decided. I can see why Rafael would
> have marked so in PM patchwork. Daniel has already acked small change in
> CPUidle config file while the bulk is removal of arm64 code. So, it is
> better to route it via arm64 tree.
> 
> Will,
> 
> Assuming you will handle v5.20, can you pick this up ?

Yup, on it.

Will