Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp885033imj; Fri, 15 Feb 2019 08:22:16 -0800 (PST) X-Google-Smtp-Source: AHgI3IbJ3Hbtq94zRGdyzrzRxqUDmGaYUDaINp5BgvjI5cZaY67YeH+ZM7Feaf1DuLgcwVZV5hh6 X-Received: by 2002:a17:902:161:: with SMTP id 88mr11284895plb.306.1550247736033; Fri, 15 Feb 2019 08:22:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550247736; cv=none; d=google.com; s=arc-20160816; b=NWmfYWXo82pCBNiJ1rHZOE0cDeuidqSN8XiT7D+tCu9+1cxO5EQw9+zYCHTIG9Nrgl 2MLrIMU8hDAipc5uOk46xgSJpXL2fuVekLma2UmvW2MXi2D/JKK+dyW9vqAElRaEO+Yf JJpgF/gNHjhiqbzkVfTlrGaqU5GLuGSRQFORizM83C7mgF/7YlrIISD65G+Ugx5xy7xz gCiMqK9BRtg37PYJIKnFJ/sbzbNhvluUoMfEveczs1uKsBlhqyilt6SP/fW/Trn/AR7h ZIyZCPiuIBNL5JGsKj9PonvHk92DOaSrM6+e4JBxUFybKHsPT16/vGlcH9vrRSUjD/wg zbgQ== 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:dkim-signature; bh=oJHQ2FurCtuTJLkPxi5192L8GxeFs8MeKxFgyYj0yrw=; b=0/xiKwde8Nz+loUG1uB+8lcw8KBLLQH2/wHW6B6FTor9nNLFLuNrqEusWAOAAcz4+D rOy5x+UsG/0qWCXD/lV1b0GEQ87AocBZvbhJSsTYdbiBtdYyqClRfRHbAmoyQaUx2fUV jEgpSAKaSO7fKiWKdh4D2xbfGkGEC1oC24W5WnoNzOBnOtPg2Inrya7k+BA6N7GnFIvd r/nVFXziEKdl2aSfOKCiNGEg8CumbCx3I+xV8Z0wUMFh3xouUQMORrwGvtioradNa3hx ufdLWDdMYRy7OssTJUzO2kvn4qTvju8DTmB9ZVgV/Aveu+BSFkqrNCdIAx0AOQKMt6jY hSrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="rXpOhQ/g"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i8si5899657pgo.273.2019.02.15.08.22.00; Fri, 15 Feb 2019 08:22:16 -0800 (PST) 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; dkim=pass header.i=@linaro.org header.s=google header.b="rXpOhQ/g"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732716AbfBOOiG (ORCPT + 99 others); Fri, 15 Feb 2019 09:38:06 -0500 Received: from mail-vk1-f196.google.com ([209.85.221.196]:38352 "EHLO mail-vk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729482AbfBOOiG (ORCPT ); Fri, 15 Feb 2019 09:38:06 -0500 Received: by mail-vk1-f196.google.com with SMTP id x140so2276502vke.5 for ; Fri, 15 Feb 2019 06:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oJHQ2FurCtuTJLkPxi5192L8GxeFs8MeKxFgyYj0yrw=; b=rXpOhQ/gIAFHs2d0uI+saOWjnYBEK0uxH3giP/LGRW4Th6lLuvO0e16PRYYdpIuJ3K pETiwX+Nr6gcZKa7rN6M4gd0LSV4e5np5hHm+R7/if4ZCBLUp68QAM0VRLZClJ9wwAfK PqeT46Ifl3HWerODkJ2CPyCXRzY4svA4WScg+AAsdB53tj7evLyQTQ7HowWvyNQGiYmt 08oKI/3bJBcYjgb9niiauqiQFxCXSD18LYt/AUkkNPriBTEmKXnw+3NJN9qiENAMS7BY XEW4/7GdYfIUXUoc/pWO8MSXkojIBipcJ4Nv7Mr+GboAW5sK7Np9DdGBoXmTugZc8Ken PgKg== 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=oJHQ2FurCtuTJLkPxi5192L8GxeFs8MeKxFgyYj0yrw=; b=pqJ4SipjFlZ4K+/FT9XtOp5mCbrFhv20Y8E2MYJY9VdyJqreKuApTrFEnm+K0PgndG SD0pfRFea9U7HjZKo4dt9quyy2Jch+x5a24I3Ij8fx1YO2ZdsyIJ3YkCMbDtmf1o+EvR GhbEGCm4wgmclXShRP6aR7y06TU40gAHymwZw+uTUfE0QS9K4CKkOBUz8ZqoLfJUKD2u IBGnj2DLfgQndlr6u089z5tiLNRDORM/zXO3rEvwwisW93DjmmaDCYimm3qjkKIpsyCZ HpQ8QvcUVPnCyiC3Bbtievc55zbsr9jK9KVXHIo28lqDd73z8JsRPelx+92fTWp37DPX PMHw== X-Gm-Message-State: AHQUAuZSALD+LFMFzQs3RgFO3df59qZ4wQiHyArHLwfzmfDxRox3yrV2 j4fUPn6uyKLUNsJin7JIMCWnrEfAGXczhattg4G+YQ== X-Received: by 2002:a1f:9042:: with SMTP id s63mr4966461vkd.17.1550241484954; Fri, 15 Feb 2019 06:38:04 -0800 (PST) MIME-Version: 1.0 References: <5510642.nRbR3bcduN@aspire.rjw.lan> <9351473.C2nPJoyFsE@aspire.rjw.lan> <2ed95b05-317c-59bb-498a-b5481e54bcf6@nvidia.com> In-Reply-To: <2ed95b05-317c-59bb-498a-b5481e54bcf6@nvidia.com> From: Ulf Hansson Date: Fri, 15 Feb 2019 15:37:28 +0100 Message-ID: Subject: Re: [PATCH 2/2] driver core: Fix possible supplier PM-usage counter imbalance To: Jon Hunter Cc: "Rafael J. Wysocki" , Greg Kroah-Hartman , LKML , Linux PM , Daniel Vetter , Lukas Wunner , Andrzej Hajda , Russell King - ARM Linux , Lucas Stach , Linus Walleij , Thierry Reding , Laurent Pinchart , Marek Szyprowski , 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 Fri, 15 Feb 2019 at 12:00, Jon Hunter wrote: > > Hi Rafael, > > On 12/02/2019 12:08, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > If a stateless device link to a certain supplier with > > DL_FLAG_PM_RUNTIME set in the flags is added and then removed by the > > consumer driver's probe callback, the supplier's PM-runtime usage > > counter will be nonzero after that which effectively causes the > > supplier to remain "always on" going forward. > > > > Namely, device_link_add() called to add the link invokes > > device_link_rpm_prepare() which notices that the consumer driver is > > probing, so it increments the supplier's PM-runtime usage counter > > with the assumption that the link will stay around until > > pm_runtime_put_suppliers() is called by driver_probe_device(), > > but if the link goes away before that point, the supplier's > > PM-runtime usage counter will remain nonzero. > > > > To prevent that from happening, first rework pm_runtime_get_suppliers() > > and pm_runtime_put_suppliers() to use the rpm_active refounts of device > > links and make the latter only drop rpm_active and the supplier's > > PM-runtime usage counter for each link by one, unless rpm_active is > > one already for it. Next, modify device_link_add() to bump up the > > new link's rpm_active refcount and the suppliers PM-runtime usage > > counter by two, to prevent pm_runtime_put_suppliers(), if it is > > called subsequently, from suspending the supplier prematurely (in > > case its PM-runtime usage counter goes down to 0 in there). > > > > Due to the way rpm_put_suppliers() works, this change does not > > affect runtime suspend of the consumer ends of new device links (or, > > generally, device links for which DL_FLAG_PM_RUNTIME has just been > > set). > > > > Fixes: e2f3cd831a28 ("driver core: Fix handling of runtime PM flags in device_link_add()") > > Reported-by: Ulf Hansson > > Signed-off-by: Rafael J. Wysocki > > --- > > > > Note that the issue had been there before commit e2f3cd831a28, but it was > > overlooked by that commit and this change is a fix on top of it, so make > > the Fixes: tag point to commit e2f3cd831a28 (instead of an earlier one > > that the patch will not be applicable to). > I noticed that yesterday's and today's -next were no longer booting on > one of our Tegra boards (Tegra210 Jetson TX2) because networking is > failing. The ethernet chip is a USB device and looking at the bootlogs I > can see that the Tegra XHCI driver is failing ... > > tegra-xusb 70090000.usb: xHCI host controller not responding, assume dead > tegra-xusb 70090000.usb: HC died; cleaning up > > The Tegra XHCI driver uses multiple power-domains and uses > device_link_add() to attach them. So now I am wondering if there is > something that we have got wrong in our implementation. However, I don't > see the device being probed deferred on boot or anything like that. > > The driver in question is drivers/usb/host/xhci-tegra.c and we add the > links in the function tegra_xusb_powerdomain_init() which is before RPM > is enabled. Let me know if you have any thoughts. If you are willing to help debugging then I am offering my assistance. I would start by enabling CONFIG_PM_ADVANCED_DEBUG, which gives you some more information about the runtime PM state of the device, like the usage count for example. I would also add a couple of prints in tegra_xusb_runtime_suspend|resume() and in the ->power_on|off() callbacks for the corresponding genpds, to see when those gets called. While I was testing $subject patch I also used a local debug patch, which adds a sysfs node that can be used to get the state of linked suppliers for a consumer device. Feel free to use it, attached below. Of course, the interesting part is the comparison of what happens with and without $subject patch. From: Ulf Hansson Date: Mon, 11 Feb 2019 15:37:44 +0100 Subject: [PATCH] PM / Runtime: Add sysfs for runtime counting of suppliers Signed-off-by: Ulf Hansson --- drivers/base/power/sysfs.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c index d713738ce796..ce5c188cdf54 100644 --- a/drivers/base/power/sysfs.c +++ b/drivers/base/power/sysfs.c @@ -537,6 +537,25 @@ static ssize_t runtime_enabled_show(struct device *dev, } static DEVICE_ATTR_RO(runtime_enabled); +static ssize_t runtime_suppliers_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct device_link *link; + int chars = 0; + + list_for_each_entry_rcu(link, &dev->links.suppliers, c_node) { + + if (!(link->flags & DL_FLAG_PM_RUNTIME)) + continue; + + chars += sprintf(buf + chars, "%s %d\n", + dev_name(link->supplier), + refcount_read(&link->rpm_active)); + } + return chars; +} +static DEVICE_ATTR_RO(runtime_suppliers); + #ifdef CONFIG_PM_SLEEP static ssize_t async_show(struct device *dev, struct device_attribute *attr, char *buf) @@ -572,6 +591,7 @@ static struct attribute *power_attrs[] = { &dev_attr_runtime_usage.attr, &dev_attr_runtime_active_kids.attr, &dev_attr_runtime_enabled.attr, + &dev_attr_runtime_suppliers.attr, #endif /* CONFIG_PM_ADVANCED_DEBUG */ NULL, }; -- 2.17.1 Kind regards Uffe