Received: by 10.223.164.202 with SMTP id h10csp3164099wrb; Tue, 28 Nov 2017 07:09:09 -0800 (PST) X-Google-Smtp-Source: AGs4zMY4mpArHYR7FS+dVQgAUMAHAe9b1wQxsblOsYtnjK4pCmgXazfaWlgNqPnWuxiutkV9Fush X-Received: by 10.98.89.220 with SMTP id k89mr41454123pfj.36.1511881749203; Tue, 28 Nov 2017 07:09:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511881749; cv=none; d=google.com; s=arc-20160816; b=YQpt/A90k5IQ7fZb2DEvpywCpbARCtCKlq30rdBaNZgC9f9g1rXgbZTuNKM8jqqhFb 9ifVYyED8q+eCjEUt2pXT3jGUM3h6kamDhfzJ6J/mBv2hiACLC1SXV4HwNhNk9c5ZyEy +UzFS9REh2MjjQ+mWZt4kcViBk9WMb/xCAW2FzbeOyiHnO3bUMKrKoWzDrKulGKnAwxR 0i+3RDtlwxAIMvUE04xCGfWrQno5uqF/SWL66zdOz2g3JN0PObROthIDqOvEV25zhyC+ NFQXIlg4qx1x1GvG6yHfmebNXzxS0+lezljCM9B7j9jjW/JsVWAI3QSy3SBtAGWKThpU uidA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=FN3K0i/QglB0jU+glPsjSyfBr2a3BOgQqyDXLFNYgPo=; b=D/0GbSI4KHQYuKZNlTkzgahHBJMAHk7zvAJJ371+w07wUjWl5dp2+TyuWwh5d/GEQg ZgGz2m3ygD17OVPn10WWp56cHXq1+Fead6bzyCPxsmbhEjamC8jpUTmE3JIRs/kn1hW/ T9Pw1ZJvxkT+8RHax6W1nAnskcRpjizPrgq7d6/KeQWc2BRCEuLOm1ZtJCk0EvP0h0+L QTekotpe6kIi/3aLXJCEQ089kzNID68La6Fmt0onenzH35BoS0NUJxw7oM9UNBxRAgb3 7KUM+Kj7igSm3KpVY5IHkIHOlzC/DIN0GRE5VH2cLxOCKRPhC2JCz8tMRqUnnUpYNcec bsfg== 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=harvard.edu Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i8si24332867pgv.239.2017.11.28.07.08.57; Tue, 28 Nov 2017 07:09:09 -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; 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=harvard.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753963AbdK1PG4 (ORCPT + 77 others); Tue, 28 Nov 2017 10:06:56 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:55072 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753813AbdK1PGj (ORCPT ); Tue, 28 Nov 2017 10:06:39 -0500 Received: (qmail 1949 invoked by uid 2102); 28 Nov 2017 10:06:38 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Nov 2017 10:06:38 -0500 Date: Tue, 28 Nov 2017 10:06:38 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Yoshihiro Shimoda cc: Geert Uytterhoeven , "Rafael J. Wysocki" , Linux PM , LKML , Ulf Hansson , Greg Kroah-Hartman , USB list , Linux-Renesas Subject: RE: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 28 Nov 2017, Yoshihiro Shimoda wrote: > Hi Geert-san, > > > From: Geert Uytterhoeven, Sent: Tuesday, November 28, 2017 7:58 PM > > > > Hi Rafael, Shimoda-san, > > > > On Sun, Nov 12, 2017 at 1:27 AM, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki > > > > > > The check for "active" children in __pm_runtime_set_status(), when > > > trying to set the parent device status to "suspended", doesn't > > > really make sense, because in fact it is not invalid to set the > > > status of a device with runtime PM disabled to "suspended" in any > > > case. It is invalid to enable runtime PM for a device with its > > > status set to "suspended" while its child_count reference counter > > > is nonzero, but the check in __pm_runtime_set_status() doesn't > > > really cover that situation. > > > > > > For this reason, drop the children check from __pm_runtime_set_status() > > > and add a check against child_count reference counters of "suspended" > > > devices to pm_runtime_enable(). > > > > > > Signed-off-by: Rafael J. Wysocki > > > --- > > > drivers/base/power/runtime.c | 30 ++++++++++-------------------- > > > 1 file changed, 10 insertions(+), 20 deletions(-) > > > > > > Index: linux-pm/drivers/base/power/runtime.c > > > =================================================================== > > > --- linux-pm.orig/drivers/base/power/runtime.c > > > +++ linux-pm/drivers/base/power/runtime.c > > > @@ -1101,29 +1101,13 @@ int __pm_runtime_set_status(struct devic > > > goto out; > > > } > > > > > > - if (dev->power.runtime_status == status) > > > + if (dev->power.runtime_status == status || !parent) > > > goto out_set; > > > > > > if (status == RPM_SUSPENDED) { > > > - /* > > > - * It is invalid to suspend a device with an active child, > > > - * unless it has been set to ignore its children. > > > - */ > > > - if (!dev->power.ignore_children && > > > - atomic_read(&dev->power.child_count)) { > > > - dev_err(dev, "runtime PM trying to suspend device but active child\n"); > > > > JFTR, this triggered before during system resume on e.g. Salvator-XS with > > R-Car H3: > > > > ohci-platform ee080000.usb: runtime PM trying to suspend device > > but active child > > phy_rcar_gen3_usb2 ee080200.usb-phy: runtime PM trying to suspend > > device but active child > > ohci-platform ee0c0000.usb: runtime PM trying to suspend device > > but active child > > ohci-platform ee0a0000.usb: runtime PM trying to suspend device > > but active child > > phy_rcar_gen3_usb2 ee0c0200.usb-phy: runtime PM trying to suspend > > device but active child > > phy_rcar_gen3_usb2 ee0a0200.usb-phy: runtime PM trying to suspend > > device but active child > > > > so this was an existing issue with USB before. > > Thank you for the report! > I know that, but since this didn't cause any trouble until now, > I postponed to investigate the issue... But, I investigate it today. > I don't find the root cause yet. However, it seems related to usb host and/or usb core. > --> USB host related devices' child_count will be 1 in suspend timing. > --> I guess remote wakeup feature is enabled? But, I don't find the point yet. > > The renesas_usbhs also uses the phy_rcar_gen3_usb2 driver. > --> If I only used the renesas_usbhs driver (in other words, I don't install > [eo]hci-{hcd,platform} drivers), the issue disappeared. > --> So, I think the phy_rcar_gen3_usb2 driver doesn't cause this issue. > (But, it is possible to be related though.) > > I'll continue to investigate this issue tomorrow. Does the phy_rcar_gen3_usb2 driver use runtime PM? It looks like the phy device somehow gets enabled for runtime PM when it shouldn't be. (And by the way, what device is the child of ee0a0200.usb-phy?) Alan Stern From 1585319712302269940@xxx Tue Nov 28 14:18:12 +0000 2017 X-GM-THRID: 1583817989870775760 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread