Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2917782ybd; Mon, 24 Jun 2019 15:21:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqz2mto1STZbBNBGVk/hMb5IzHlrTCHl1+l2RCEM4hqAwy4a2Ss9TtkweNcZK5vqn4zoBWsl X-Received: by 2002:a17:90a:3585:: with SMTP id r5mr28663125pjb.15.1561414888397; Mon, 24 Jun 2019 15:21:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561414888; cv=none; d=google.com; s=arc-20160816; b=ZE9oO+KeaE0tWvYqa8rmJAyKcLSLHvnF2ATqw0HhRRIHe2/JEtfa287pjMy6HVujMV EWx/7Q1q1ubutDAKa3bb1PriAo8oprReQtt7pn+PTsrIkQaFJ2XfGxUUEYXvqN3bwYbT 70pASYDzWXUb0FTfySSQaAiKim38GdBmcXYTYOphKYKNmrvKgNORAtTFlQl8D3OfSadr Kf8/zOI8IGZQtuNUzbkhInCBw/oncwvxPOrjSeB540bTsl72iO5n0YQc7H80R1O9ER6A SnoNs2a8R4neXyu2NjuWJPPuUVSWz3xc4Itp0nqdZlLsSDRapc3jRj3I3YYIBQ6NnyP4 TUOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=X2mdj71OojvPofZElDA3A0qbxcCan0Gcd6RJ7oQb2rg=; b=Q53UUcrxkYa2HHINQ/sZZyHwyb6QpHrBFGUlSIehcz43HjUJj9gGYQmIMKbCqU2Yp0 8/oiSKS9RBzGukKNW8bV3PsQRL7eJi+2AfZLUxnKollgpvQeNPj8osGVQxzWe9XlA2/I YbOmYMZDGqBiSYtNNOE+0FzIli6Xq8tTV6l2tsp7V+WJ+tnbmNMdjMfx8OFYJ6RBBc7i xXFyhAYfu5TQRSuCpJq/KIPQpDDGPm8eUNs4C2wTxPpkVfqFRNd2X+xnfXKx1/6bI4vU uVy2PjN6CEgNyhbMTQw8OU9Zj1nu7f4vSoQm4Q0L7BGAYgEnLS1Ng3qbXo7JGRIGmD7d nubA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u6si11743954pga.360.2019.06.24.15.21.12; Mon, 24 Jun 2019 15:21:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727026AbfFXWUj (ORCPT + 99 others); Mon, 24 Jun 2019 18:20:39 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:33134 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725268AbfFXWUi (ORCPT ); Mon, 24 Jun 2019 18:20:38 -0400 Received: by mail-oi1-f195.google.com with SMTP id f80so11024202oib.0; Mon, 24 Jun 2019 15:20:38 -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=X2mdj71OojvPofZElDA3A0qbxcCan0Gcd6RJ7oQb2rg=; b=LgDpIeDj2w9bJ1yoOEsam4nLZOGjutw/qb6JzKt+Artj50DG+px7jEyjkLj7BOX5Ua NHPrDdr4HAQqdX+d1ufA2N0I0kRxKfsWI1ULlUXzYkzgmYmmEX8dheNgo+uodJK/zlQ9 DShe0xXP2O68QhF1oL2sLYYDTsDQEcPCnCu7dFeiiYAOcjJBvjfG3sVz7uyST6LgRMrg u1IX2fngxb4Zsic/8ep5Wzp/hBqL3tUGOLnJGlIRIN2n+rsFGCEKBD/bXuguQJweQJjh GyqUUc+9fyubnFukEoZri5HykTSWA2gZrK2quECdK94KMjGbErQR7eGWHuSF9uEuHfMJ YAFg== X-Gm-Message-State: APjAAAWgMRMAuQbuZLoDCwUDJ+LmWJpT1zuUVndQJFfG80CIkuM0yQJZ 8hIrlhvHek1R5nWGRdO0dEnm+t0ekW/prPTDHNKNEVog X-Received: by 2002:aca:edc8:: with SMTP id l191mr12597021oih.103.1561414837894; Mon, 24 Jun 2019 15:20:37 -0700 (PDT) MIME-Version: 1.0 References: <1668247.RaJIPSxJUN@kreacher> <9906d02b-8c77-f2c8-7168-93ea444b950e@nvidia.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Tue, 25 Jun 2019 00:20:26 +0200 Message-ID: Subject: Re: [PATCH v2] PCI: PM: Skip devices in D0 for suspend-to-idle To: Jon Hunter Cc: Linux PCI , Bjorn Helgaas , Linux PM , Linux ACPI , LKML , Mika Westerberg , Keith Busch , Kai-Heng Feng , linux-tegra Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 24, 2019 at 11:37 PM Rafael J. Wysocki wrote: > > On Mon, Jun 24, 2019 at 2:43 PM Jon Hunter wrote: > > > > Hi Rafael, > > > > On 13/06/2019 22:59, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki > > > > > > Commit d491f2b75237 ("PCI: PM: Avoid possible suspend-to-idle issue") > > > attempted to avoid a problem with devices whose drivers want them to > > > stay in D0 over suspend-to-idle and resume, but it did not go as far > > > as it should with that. > > > > > > Namely, first of all, the power state of a PCI bridge with a > > > downstream device in D0 must be D0 (based on the PCI PM spec r1.2, > > > sec 6, table 6-1, if the bridge is not in D0, there can be no PCI > > > transactions on its secondary bus), but that is not actively enforced > > > during system-wide PM transitions, so use the skip_bus_pm flag > > > introduced by commit d491f2b75237 for that. > > > > > > Second, the configuration of devices left in D0 (whatever the reason) > > > during suspend-to-idle need not be changed and attempting to put them > > > into D0 again by force is pointless, so explicitly avoid doing that. > > > > > > Fixes: d491f2b75237 ("PCI: PM: Avoid possible suspend-to-idle issue") > > > Reported-by: Kai-Heng Feng > > > Signed-off-by: Rafael J. Wysocki > > > Reviewed-by: Mika Westerberg > > > Tested-by: Kai-Heng Feng > > > > I have noticed a regression in both the mainline and -next branches on > > one of our boards when testing suspend. The bisect is point to this > > commit and reverting on top of mainline does fix the problem. So far I > > have not looked at this in close detail but kernel log is showing ... > > Can you please collect a log like that, but with dynamic debug in > pci-driver.c enabled? > > Note that reverting this commit is rather out of the question, so we > need to get to the bottom of the failure. I suspect that there is a problem with the pm_suspend_via_firmware() check which returns 'false' on the affected board, but the platform actually removes power from devices left in D0 during suspend. I guess it would be more appropriate to check something like pm_suspend_no_platform() which would return 'true' in the suspend-to-idle patch w/ ACPI.