[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <TY1PR06MB0992899AE427576E3F83CF54D83B0@TY1PR06MB0992.apcprd06.prod.outlook.com>
Date: Wed, 29 Nov 2017 08:21:22 +0000
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>
To: Alan Stern <stern@...land.harvard.edu>
CC: Geert Uytterhoeven <geert@...ux-m68k.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux PM <linux-pm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
USB list <linux-usb@...r.kernel.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>
Subject: RE: [PATCH] PM / runtime: Drop children check from
__pm_runtime_set_status()
Hi,
> From: Alan Stern, Sent: Wednesday, November 29, 2017 12:07 AM
>
> 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 <rjw@...ysocki.net> wrote:
> > > > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
<snip>
> > > 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.
I'm so sorry, but this is mistake.
The renesas_usbhs doesn't use the phy_rcar_gen3_usb2 driver.
So,
> > --> 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.)
They are also mistake.
> > I'll continue to investigate this issue tomorrow.
>
> Does the phy_rcar_gen3_usb2 driver use runtime PM?
Yes, the phy_rcar_gen3_usb2 uses runtime PM.
> It looks like the
> phy device somehow gets enabled for runtime PM when it shouldn't be.
I also think that now.
I don't find why for now, but the usage_count of a phy device was not 1 just before suspend.
(This "a phy device" means the child of ee0a0200.usb-phy device.)
> (And by the way, what device is the child of ee0a0200.usb-phy?)
It's a phy device:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/phy/phy-core.c?h=v4.15-rc1#n773
Best regards,
Yoshihiro Shimoda
> Alan Stern
Powered by blists - more mailing lists