From patchwork Sat Feb 24 00:46:49 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Kan X-Patchwork-Id: 10240073 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6522B60390 for ; Sat, 24 Feb 2018 00:47:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 54F7A29A75 for ; Sat, 24 Feb 2018 00:47:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 48FFC29AA2; Sat, 24 Feb 2018 00:47:27 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id CF06B29A75 for ; Sat, 24 Feb 2018 00:47:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=9RpNCIRzRZ46eTDsajWLvHmz/vqhdNVC9RI9HS3p3Is=; b=VRS RxScJutfvfaAtlrDH0GNAUMcD5+X4lYJofTNYVaPr9Sd/6WVEcBQwAhqJUIHedVZHeB3Lxj7Qrv9H Xhckc1NtTSpp2NoZBLRFEapTy+1DoPM0P9V9PgBn1jmg1GfQYILqyj0OikcEDHxTr9DKTghxKaD7c 9/Ln868Yu4JpeMkB/a2ilUH8GkkKVLUPPI0g6Ga4NeBU81rlZD5xZ4rlGexqKyQUV+ik2VIEG1Trw Y05QGhCycA/g4B8Obg5r7gnMEooHTVrC+jczv1ZzySsYH2eyNN4u2F/kWtUGOOArZ5CJMLBf9rSAO 2Q2wgRI+vBhbPS/+scgT/xpk6nZ/scw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.89 #1 (Red Hat Linux)) id 1epNzh-0001lo-RC; Sat, 24 Feb 2018 00:47:17 +0000 Received: from mail-pg0-x243.google.com ([2607:f8b0:400e:c05::243]) by bombadil.infradead.org with esmtps (Exim 4.89 #1 (Red Hat Linux)) id 1epNzd-0001kL-42 for linux-arm-kernel@lists.infradead.org; Sat, 24 Feb 2018 00:47:14 +0000 Received: by mail-pg0-x243.google.com with SMTP id y26so3983647pgv.4 for ; Fri, 23 Feb 2018 16:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apm.com; s=apm; h=from:to:cc:subject:date:message-id; bh=ub/MkWy76lgZ8Ki4+XuvLmyZ6oSXujZU6Gtb8AY+MQw=; b=gAVlaOLvKI2C4J2ai312/uyEDYVBogF4qV0qykLmhbuHmJCri3HwzhrCYB2NOiltmj g3sk/P6HzhbLny+gTrgvMYJFj53z2YbRKCTXmj3EtMB2QauIF8dtLgJPRSV+p5gJJiPG rzuEB74PRXv2P6sUu2LAuaj2C5/a+t1mMGEag= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=ub/MkWy76lgZ8Ki4+XuvLmyZ6oSXujZU6Gtb8AY+MQw=; b=c9KXbohL0OaJKPxwGuK9Pq6HtBUMEzTnks7aHLeLfNn8VLnfhirDkCDHmUOS/NihZH J52fMWs0OTJ53xoPDhr0HYCTAmOzgs/rNE/UbxdKlxeFCk3Yx4uDofwd+0B4pwsA0cEF 3exlOZ2A6TWq5nv5EUMNg9IGmHgyXz3QO20Af4RD9wVHjqY7+v2LMnpWOCgyLkSh2AKC 5M9/JtJNaqQn5inkkcE0LiOdx/t3eus1XcQ0qlKUJa/1Tz9P8AyXQIMYO6UFss/Js36+ yfxugiK8NgRzDW3hE22m17ExWH/YKhLVrWUWg26dIq/SBdvEIcc01HTk8JbI5Md3ZwZ8 gFjg== X-Gm-Message-State: APf1xPBhtFV+DXfxbOmB4cVarGJmDQylUvqyVJohD6aCwifkGtyYgor7 2btBipd/q5bVz+tioqeV/Muv0W/r X-Google-Smtp-Source: AH8x224+n7Vnz7Dt5wtVk2he+flqOL+RyVS93doo2F0PF37n7eRW8wAxrUNNZz8wtg/VYATUp61f5g== X-Received: by 10.98.62.196 with SMTP id y65mr3412256pfj.24.1519433220840; Fri, 23 Feb 2018 16:47:00 -0800 (PST) Received: from goldengate.amcc.com ([206.80.4.98]) by smtp.gmail.com with ESMTPSA id x86sm7140066pfa.164.2018.02.23.16.46.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Feb 2018 16:46:59 -0800 (PST) From: Feng Kan To: rjw@rjwysocki.net, linux-pm@vger.kernel.org, lorenzo.pieralisi@arm.com, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, bhelgaas@google.com Subject: [PATCH] PCIe bridge deferred probe breaks suspend resume Date: Fri, 23 Feb 2018 16:46:49 -0800 Message-Id: <1519433209-14581-1-git-send-email-fkan@apm.com> X-Mailer: git-send-email 2.7.4 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180223_164713_179616_86E07856 X-CRM114-Status: GOOD ( 15.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Feng Kan MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP This is not a patch, but rather a question regarding the deferred probe's effect on PCIe PM ordering. This happens on our system which defer the probing of root bridge due to the IOMMU not being ready. Because of the deferred action, the bridge is moved to the end of the dpm_list which results in incorrect suspend and resume sequence. In the cases I have seen, the bridge is always reordered because of startup sequence. They are always place after the endpoint. If that is the case the following code should be able to prevent such cases. However, is there some cases here that would violate such situation? --- drivers/base/dd.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index de6fd09..5b96d5c 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -116,15 +116,17 @@ static void deferred_probe_work_func(struct work_struct *work) */ mutex_unlock(&deferred_probe_mutex); - /* - * Force the device to the end of the dpm_list since - * the PM code assumes that the order we add things to - * the list is a good order for suspend but deferred - * probe makes that very unsafe. - */ - device_pm_lock(); - device_pm_move_last(dev); - device_pm_unlock(); + if (!dev_is_pci(dev)) { + /* + * Force the device to the end of the dpm_list since + * the PM code assumes that the order we add things to + * the list is a good order for suspend but deferred + * probe makes that very unsafe. + */ + device_pm_lock(); + device_pm_move_last(dev); + device_pm_unlock(); + } dev_dbg(dev, "Retrying from deferred list\n"); if (initcall_debug && !initcalls_done)