Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Rafael J. Wysocki" <rjw@rjwysocki.net>
To:     Mika Westerberg <mika.westerberg@linux.intel.com>
Cc:     Alan Stern <stern@rowland.harvard.edu>,
        Linux PM <linux-pm@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux ACPI <linux-acpi@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH] PM: sleep: core: Fix the handling of pending runtime resume requests
Date:   Mon, 24 Aug 2020 15:38:39 +0200
Message-ID: <2486532.D7zGhtygOF@kreacher>
In-Reply-To: <20200824083452.GX1375436@lahna.fi.intel.com>
References: <7969920.MVx1BpXlEM@kreacher> <20200821193442.GA264863@rowland.harvard.edu> <20200824083452.GX1375436@lahna.fi.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Monday, August 24, 2020 10:34:52 AM CEST Mika Westerberg wrote:
> Hi,
> 
> On Fri, Aug 21, 2020 at 03:34:42PM -0400, Alan Stern wrote:
> > This means that the code could be simplified to just:
> > 
> > 	pm_runtime_barrier(dev);
> > 
> > Will this fix the reported bug?  It seems likely to me that the actual 
> > problem with the failure scenario in the patch description was that 
> > turning on an ACPI power resource causes runtime-resume requests to be 
> > queued for all devices sharing that resource.  Wouldn't it make more 
> > sense to resume only the device that requested it and leave the others 
> > in runtime suspend?
> 
> The problem with at least PCIe devices that share ACPI power resources
> is that once you turn on the power resource all the devices that shared
> it will go into D0uninitialized power state and that means they lose all
> wake configuration etc. so they need to be re-initialized by their
> driver before they can go back to D3(cold) in order for their wakes to
> still work.

Plus devices in D0uninitialized may prevent the SoC from allowing package
C-states to be used for the processor AFAICS.

BTW, does the patch make the issue at hand go away?