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 S1756495AbbBLQZf (ORCPT <rfc822;w@1wt.eu>);
	Thu, 12 Feb 2015 11:25:35 -0500
Received: from casper.infradead.org ([85.118.1.10]:45073 "EHLO
	casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756278AbbBLQZc (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 12 Feb 2015 11:25:32 -0500
Date: Thu, 12 Feb 2015 17:25:25 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Thomas Gleixner <tglx@linutronix.de>, Alan Cox <alan@linux.intel.com>,
        "Li, Aubrey" <aubrey.li@linux.intel.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux PM list <linux-pm@vger.kernel.org>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        Kristen Carlson Accardi <kristen@linux.intel.com>,
        John Stultz <john.stultz@linaro.org>, Len Brown <len.brown@intel.com>
Subject: Re: [PATCH 5/6] intel_idle: Add ->enter_freeze callbacks
Message-ID: <20150212162525.GW5029@twins.programming.kicks-ass.net>
References: <8292243.ibkmfVtXac@vostro.rjw.lan>
 <2407992.WHaFxrNaoa@vostro.rjw.lan>
 <20150212132643.GY23123@twins.programming.kicks-ass.net>
 <25445086.IBiaGBbm1j@vostro.rjw.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <25445086.IBiaGBbm1j@vostro.rjw.lan>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Feb 12, 2015 at 05:24:51PM +0100, Rafael J. Wysocki wrote:
> On Thursday, February 12, 2015 02:26:43 PM Peter Zijlstra wrote:

> > Why bother with enter_freeze() for any but the deepest state (C6 in this
> > case)?
> 
> User space may disable the deepest one (and any of them in general) via sysfs
> and there's no good reason to ignore its choice in this particular case while
> we're honoring it otherwise.
> 
> So the logic is basically "find the deepest one which isn't disabled" and
> setting the pointers costs us nothing really.
> 
> > Also, should we ignore things like intel_idle.max_cstate for this
> > selection?
> 
> No, we shouldn't.  The deeper ones may just not work then.

OK, fair enough.