From patchwork Sat Dec 27 20:22:56 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 424249 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 090811400E2 for ; Sun, 28 Dec 2014 07:01:04 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751625AbaL0UBC (ORCPT ); Sat, 27 Dec 2014 15:01:02 -0500 Received: from v094114.home.net.pl ([79.96.170.134]:52695 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751581AbaL0UBB (ORCPT ); Sat, 27 Dec 2014 15:01:01 -0500 Received: from aayg134.neoplus.adsl.tpnet.pl (83.6.118.134) (HELO vostro.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer v0.80) id 6e987aecc04a15ab; Sat, 27 Dec 2014 21:00:59 +0100 From: "Rafael J. Wysocki" To: Pali =?ISO-8859-1?Q?Roh=E1r?= Cc: nick , Daniel Vetter , Jani Nikula , David Airlie , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Len Brown , linux-acpi@vger.kernel.org, Bjorn Helgaas , linux-pci@vger.kernel.org, Mika Westerberg , Andy Shevchenko Subject: Re: [Intel-gfx] 3.19-rc1 errors when opening LID Date: Sat, 27 Dec 2014 21:22:56 +0100 Message-ID: <1818900.MY9q0yfluC@vostro.rjw.lan> User-Agent: KMail/4.11.5 (Linux/3.16.0-rc5+; KDE/4.11.5; x86_64; ; ) In-Reply-To: <201412270919.49540@pali> References: <201412241951.48652@pali> <549C4278.5080707@gmail.com> <201412270919.49540@pali> MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Saturday, December 27, 2014 09:19:49 AM Pali Rohár wrote: > Hello, > > in attachment is output of ls -l /sys/bus/acpi/devices from both > 3.13 and 3.19 kernels. > > Anyway Gabriele Mazzotta wrote me that new acpi devices could be > created after commit faae404ebdc6bba (ACPICA: Add "Windows 2013" > string to _OSI support). > > Maybe this another output could help you: > > $ cat /sys/bus/acpi/devices/INT33C5\:00/status > 0 > $ cat /sys/bus/acpi/devices/INT33C5\:00/power_state > (unknown) > > Device INT33C5 is in that dmesg log: > acpi INT33C5:00: Cannot transition to non-D0 state from D3 The appended patch should make these messages go away, please test. > And status 0 in sysnode could indicate that acpi device is not > present right? That's correct. --- drivers/acpi/device_pm.c | 7 ++++--- include/acpi/acpi_bus.h | 3 ++- 2 files changed, 6 insertions(+), 4 deletions(-) Index: linux-pm/include/acpi/acpi_bus.h =================================================================== --- linux-pm.orig/include/acpi/acpi_bus.h +++ linux-pm/include/acpi/acpi_bus.h @@ -589,7 +589,8 @@ static inline u32 acpi_target_system_sta static inline bool acpi_device_power_manageable(struct acpi_device *adev) { - return adev->flags.power_manageable; + return adev->flags.power_manageable + && (adev->status.present || adev->status.functional); } static inline bool acpi_device_can_wakeup(struct acpi_device *adev) Index: linux-pm/drivers/acpi/device_pm.c =================================================================== --- linux-pm.orig/drivers/acpi/device_pm.c +++ linux-pm/drivers/acpi/device_pm.c @@ -68,7 +68,8 @@ int acpi_device_get_power(struct acpi_de { int result = ACPI_STATE_UNKNOWN; - if (!device || !state) + if (!device || !state + || !(device->status.present || device->status.functional)) return -EINVAL; if (!device->flags.power_manageable) { @@ -156,7 +157,7 @@ int acpi_device_set_power(struct acpi_de int result = 0; bool cut_power = false; - if (!device || !device->flags.power_manageable + if (!device || !acpi_device_power_manageable(device) || (state < ACPI_STATE_D0) || (state > ACPI_STATE_D3_COLD)) return -EINVAL; @@ -361,7 +362,7 @@ bool acpi_bus_power_manageable(acpi_hand int result; result = acpi_bus_get_device(handle, &device); - return result ? false : device->flags.power_manageable; + return result ? false : acpi_device_power_manageable(device); } EXPORT_SYMBOL(acpi_bus_power_manageable);