From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753448AbeADPrY (ORCPT + 1 other); Thu, 4 Jan 2018 10:47:24 -0500 Received: from mga01.intel.com ([192.55.52.88]:2896 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752801AbeADPrW (ORCPT ); Thu, 4 Jan 2018 10:47:22 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,507,1508828400"; d="scan'208";a="8482835" Subject: Re: [char-misc-next] mei: me: allow runtime pm for platform with D0i3 To: "Winkler, Tomas" Cc: Greg Kroah-Hartman , "Usyskin, Alexander" , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" References: <20180102100141.703-1-tomas.winkler@intel.com> <5B8DA87D05A7694D9FA63FD143655C1B74A8C3F3@hasmsx108.ger.corp.intel.com> From: "Rafael J. Wysocki" Organization: Intel Technology Poland Sp. z o. o., KRS 101882, ul. Slowackiego 173, 80-298 Gdansk Message-ID: Date: Thu, 4 Jan 2018 16:47:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5B8DA87D05A7694D9FA63FD143655C1B74A8C3F3@hasmsx108.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 1/4/2018 9:27 AM, Winkler, Tomas wrote: > mei: me: allow runtime pm for platform with >> D0i3 >> >> On 1/2/2018 11:01 AM, Tomas Winkler wrote: >>> From the pci power documentation: >>> "The driver itself should not call pm_runtime_allow(), though. >>> Instead, it should let user space or some platform-specific code do >>> that (user space can do it via sysfs as stated above)..." >>> >>> However, the S0ix residency cannot be reached without MEI device >>> getting into low power state. Hence, for mei devices that support >>> D0i3, it's better to make runtime power management mandatory and not >>> rely on the system integration such as udev rules. >> It still is not mandatory with this change.  The default changes from "on" to >> "auto", but still user space can change it back to "on". > That's correct, maybe better statement would be 'default setting' instead of 'mandatory'. > I can respin the patch if needed, let me know. Greg has applied it already it seems, so I guess that shouldn't be necessary. :-) Thanks, Rafael