[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <573448A0.5030003@arm.com>
Date: Thu, 12 May 2016 10:10:56 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Len Brown <lenb@...nel.org>
Cc: Sudeep Holla <sudeep.holla@....com>,
linux acpi <linux-acpi@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Vikas Sajjan <vikas.cha.sajjan@....com>,
Sunil <sunil.vl@....com>,
Prashanth Prakash <pprakash@...eaurora.org>,
Ashwin Chaugule <ashwin.chaugule@...aro.org>,
Al Stone <al.stone@...aro.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
X86 ML <x86@...nel.org>, linux-ia64@...r.kernel.org
Subject: Re: [PATCH v5 1/5] ACPI / processor_idle: introduce
ACPI_PROCESSOR_CSTATE
(I seem to have 2 emails, replying on the second)
On 11/05/16 19:28, Len Brown wrote:
> What is the functional goal/purpose of adding CONFIG_ACPI_PROCESSOR_CSTATE?
>
Avoid adding unnecessary dummy implementations of functions and
variables that will never be used on ARM64 and also looks ugly IMO.
E.g.: arch_safe_halt
boot_option_idle_override
IDLE_NOMWAIT
acpi_unlazy_tlb
acpi_processor_cstate_check
disabled_by_idle_boot_param and more...
> If the answer is that it saves code space on an ARM build, how much
> space does it save?
>
NO, it doesn't even add a kB of code I believe, so that's definitely not
the reason. I am fine to retain if we can find a saner way to solve the
above issue.
--
Regards,
Sudeep
Powered by blists - more mailing lists