linux-kernel - RE: [PATCH] PM / runtime: Drop children check from __pm_runtime_set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 Nov 2017 12:51:45 +0000
From:   Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>
CC:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux PM <linux-pm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        Alan Stern <stern@...land.harvard.edu>,
        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: Ulf Hansson, Sent: Wednesday, November 29, 2017 6:59 PM
> 
> On 29 November 2017 at 10:43, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > Hi Ulf,
<snip>
> Okay, so the problem remains no matter which solution for wakeup you
> pick in genpd.

Yes. Today I could reproduce this issue without usb host driver.
- The renesas_usb3 usb peripheral driver has generic phy handling.
  (The peripheral driver uses different generic phy driver (phy-rcar-gen3-usb3.c) though.)
 --> If I used the current renesas_usb3 (this means doesn't call phy_power_{on,off}(),
     the issue didn't happen.
 --> If I added phy_power_{on,off}() calling, the issue happened.
  --> So, I'm thinking the APIs are related to the issue.

- The generic phy APIs are in drivers/phy/phy-core.c.
 --> The phy-rcar-gen3-usb[23] drivers call only pm_runtime_enable() before devm_phy_create().
  --> The phy-core will call pm_runtime_{get_sync,put}() in phy_{init,exit,power_{on,off}}.
   --> So, IIUC, both devices of phy-<dev_name>.<id> and <dev_name> will be handled by runtime PM APIs.
 --> The runtime PM implementation of phy-core seems good to me. But...?

> Then this seems to point to that the driver may be misbehaving in some
> way. I can help to check what is going on.

I guess so. But, I don't find yet...

Best regards,
Yoshihiro Shimoda

> Kind regards
> Uffe