From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756331AbcBVX22 (ORCPT <rfc822;w@1wt.eu>);
	Mon, 22 Feb 2016 18:28:28 -0500
Received: from mail-lb0-f170.google.com ([209.85.217.170]:35898 "EHLO
	mail-lb0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752025AbcBVX2Y (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 22 Feb 2016 18:28:24 -0500
MIME-Version: 1.0
In-Reply-To: <56CB1132.1060202@arm.com>
References: <1449065446-26115-1-git-send-email-sudeep.holla@arm.com>
	<1449065446-26115-5-git-send-email-sudeep.holla@arm.com>
	<12469811.iv3SctjXxl@vostro.rjw.lan>
	<56C465CE.50403@arm.com>
	<56CB1132.1060202@arm.com>
Date: Tue, 23 Feb 2016 00:28:22 +0100
X-Google-Sender-Auth: XGXB1li6nTkln9Fs7BVv_JCFEfY
Message-ID: <CAJZ5v0jUMcfJw983eJwXExc2Du2Vuycb5A_X+S_QwJzyAysO5g@mail.gmail.com>
Subject: Re: [PATCH v3 4/5] ACPI / processor_idle : introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
        x86@kernel.org, Al Stone <al.stone@linaro.org>,
        Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
        Mahesh Sivasubramanian <msivasub@codeaurora.org>,
        Ashwin Chaugule <ashwin.chaugule@linaro.org>,
        Prashanth Prakash <pprakash@codeaurora.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 22, 2016 at 2:46 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Hi Rafael,
>
> On 17/02/16 12:21, Sudeep Holla wrote:
>>
>>
>>
>> On 16/02/16 20:18, Rafael J. Wysocki wrote:
>
>
> [..]
>
>>
>>> This way it all should work without any new Kconfig options.
>>>
>>
>> I agree with you in terms of avoiding new Kconfig option. However the
>> main reason for adding it is to avoid declaring dummy functions and
>> variables on ARM64.
>>
>> It's hard to justify the maintainers as it's totally useless on ARM64.
>> E.g. boot_option_idle_override, IDLE_NOMWAIT, acpi_unlazy_tlb,
>> arch_safe_halt.
>>
>> Other option is to push those under CONFIG_X86, but then I don't have
>> much idea on what are all needed for IA64, so took an option that
>> encapsulates everything under CSTATE feature Kconfig, which is not user
>> visible and selected by archs supporting it by default.
>>
>> I am open to any other alternative.
>>
>
> Whatever alternative methods I tried so far ended up much horrible than
> this. So any suggestions are much appreciated.

Well, you have to give me some time here, sorry.

I'm still not done with cpufreq at this point and it's going to
consume some more cycles I'm afraid.

Thanks,
Rafael