From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9E03C48BD4 for ; Tue, 25 Jun 2019 10:01:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B7FFB20883 for ; Tue, 25 Jun 2019 10:01:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561456869; bh=kDL6F3QIj2MWeXjadYPkbJ69Rp1pEcsdPTWKJWSJ6BY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=grgDrf64Z3gujxWhwfrnUll3aZSMeOZAXqZwr6FRABXUTH0mP7L0nGlzOqqtECKhA Ydr8dUJCQy+Y15R2NmMTzcn/PcsSAf+UhsdKJMCDL/jXwkcIwmhs/ea1iWS1ZEctwl Q9jJMKvOdPgoe0WrXmf2Pvzev2SxSDx/u48EYSDY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728745AbfFYKBJ (ORCPT ); Tue, 25 Jun 2019 06:01:09 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:33375 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726421AbfFYKBJ (ORCPT ); Tue, 25 Jun 2019 06:01:09 -0400 Received: by mail-oi1-f194.google.com with SMTP id f80so12069258oib.0; Tue, 25 Jun 2019 03:01:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JMxWO1OBCSHYptcHpVKv+zvrOqzJ4t8VzgQk1UXHXpM=; b=I6RXOB7X1QxbOw8pTyinptBWjwvlN97nM/JT7uY0KM78+Bp5EPHiZO47je3vatKdfv tqJJF/FKF3ZH3mj0dKU2zuE7q1ZqiOur4pPg/jVgreYTzOM9s7Gi/j5aFXhJT762HECO vnN8BbkfKr8hjjcVVFA/zUgu4vU+4reH/BKiFfCY/FPgZkgcK5g9CkKKXgBW2Jk/bQ+C PKxngxfyPiLaD1r44SXQ1vMwTqyPnH/7Tl+qnYszQaf9Es31squ/G5panyn7bkMkQfsm Zqdhlao7T+Hu0BOs4o39ccyFUBx7KHoA2upQScKdZZPeB0JiA5NmT0a1xzxw3wb9QlWk Efbw== X-Gm-Message-State: APjAAAXYEc7m/f949vj5Q5mE0N33dttfHjOEq1AJNHE9n6PbChLLi86U odWeTDTMlzVxvPYlWnsN57eEIBN+6UsaRAV3iio= X-Google-Smtp-Source: APXvYqyvEbO5+dzT000ZqMwhIzQKRhsZ5mg1mrS4X4cHDD+Gdn62RbLCOk0KctWGppTeO9l7AUsxs56oGej4Rc34XWg= X-Received: by 2002:aca:edc8:: with SMTP id l191mr14105958oih.103.1561456868290; Tue, 25 Jun 2019 03:01:08 -0700 (PDT) MIME-Version: 1.0 References: <20190618161858.77834-1-mika.westerberg@linux.intel.com> <20190620141541.GA257318@google.com> <1858642.x2LvR771H8@kreacher> <20190625094559.GY2640@lahna.fi.intel.com> In-Reply-To: <20190625094559.GY2640@lahna.fi.intel.com> From: "Rafael J. Wysocki" Date: Tue, 25 Jun 2019 12:00:57 +0200 Message-ID: Subject: Re: [PATCH v2 1/3] PCI / ACPI: Use cached ACPI device state to get PCI device power state To: Mika Westerberg Cc: "Rafael J. Wysocki" , Bjorn Helgaas , Len Brown , Lukas Wunner , Keith Busch , Alex Williamson , Alexandru Gagniuc , ACPI Devel Maling List , Linux PCI Content-Type: text/plain; charset="UTF-8" Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Tue, Jun 25, 2019 at 11:46 AM Mika Westerberg wrote: > > On Mon, Jun 24, 2019 at 01:14:47PM +0200, Rafael J. Wysocki wrote: > > > The problem here is that acpi_device_get_power() really only should be > > > used for two purposes: (1) To initialize adev->power.state, or to > > > update it via acpi_device_update_power(), and (2) by the > > > "real_power_state" sysfs attribute (of ACPI device objects). The > > > adev->power.state value should be used anywhere else, in principle, so > > > the Mika's patch is correct. > > > > Well, it is an improvement, but it is not sufficient. > > > > > [Note that adev->power.state cannot be updated after calling > > > acpi_device_get_power() to the value returned by it without updating > > > the reference counters of the power resources that are "on" *exactly* > > > because of the problem at hand here.] > > > > That is obviously correct, but -> > > > > > > but that's just an idle thought, not a suggestion. > > > > > > After the initialization of the ACPI subsystem, the authoritative > > > source of the ACPI device power state information is > > > adev->power.state. The ACPI subsystem is expected to update this > > > value as needed going forward (including system-wide transitions like > > > resume from S3). > > > > -> the "resume from S3 or hibernation" case needs special handling, because > > in that case the device power state need not reflect the information the ACPI > > subsystem has. That only matters if adev->power.state is ACPI_STATE_D0 and > > the device is actually *not* in D0, because in that case acpi_device_set_power() > > will not work. > > I guess you are talking about the special-cased devices that we leave in > D0 when system suspend (via firmware) is entered? > > > So that case is not covered currently (it should be rare in practice, > > though, if it happens at all), so something like the patch below (untested) may > > be needed in addition to the Mika's patch. > > Looks good to me. I actually decided to address this issue in acpi_device_set_power() as it may affect devices beyond PCI in principle. I will send a patch for that shortly. > > Still, there is also the "power state not matching" case in pci_pm_complete() that's > > need to be covered and the non-PCI ACPI PM has a similar issue in theory, so I > > need to think about this a bit more. > > Do you want me to hold off sending an updated version of the patch > series while we figure this one out or is it fine if I send it out now > and we can add further details on top? It is independent of the other fix, so it can be sent now just fine IMO.