From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757251AbdLWBuP (ORCPT ); Fri, 22 Dec 2017 20:50:15 -0500 Received: from mail-ot0-f182.google.com ([74.125.82.182]:45685 "EHLO mail-ot0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757216AbdLWBuN (ORCPT ); Fri, 22 Dec 2017 20:50:13 -0500 X-Google-Smtp-Source: ACJfBotsVuh/GSfZ/NUJ7BelzzbmLyMtudHYzRuD8vk2oW03zw4vU9wKKh/6yZ9CGp7dFUj/Av0jMbuWFsDzOClj8g0= MIME-Version: 1.0 In-Reply-To: References: <1513778960-10073-1-git-send-email-ulf.hansson@linaro.org> <1513778960-10073-2-git-send-email-ulf.hansson@linaro.org> From: "Rafael J. Wysocki" Date: Sat, 23 Dec 2017 02:50:12 +0100 X-Google-Sender-Auth: lz_S9GWdmOMhqmZi0xAzXlesYUs Message-ID: Subject: Re: [PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device To: "Rafael J. Wysocki" Cc: Ulf Hansson , Kishon Vijay Abraham I , Linux Kernel Mailing List , "Rafael J . Wysocki" , Linux PM , Yoshihiro Shimoda , Geert Uytterhoeven , Linux-Renesas Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 23, 2017 at 2:35 AM, Rafael J. Wysocki wrote: > On Thu, Dec 21, 2017 at 11:50 AM, Ulf Hansson wrote: >> On 21 December 2017 at 02:39, Rafael J. Wysocki wrote: >>> On Wed, Dec 20, 2017 at 3:09 PM, Ulf Hansson wrote: >>>> The runtime PM deployment in the phy core is deployed using the phy core >>>> device, which is created by the phy core and assigned as a child device of >>>> the phy provider device. [cut] >> >> Also, I have considered how to deal with wakeup paths for phys, >> although I didn't want to post changes as a part of this series, but >> maybe I should to give a more complete picture? > > Yes, you should. > > The point is that without genpd using pm_runtime_force_suspend() the > phy code could very well stay the way it is. And it is logical, > because having a parent with enabled runtime PM without enabling > runtime PM for its children is at least conceptually questionable. Actually, I sort of agree that the phy's usage of runtime PM is too convoluted. For example, it uses pm_runtime_enabled() unnecessarily at least in some places, but that doesn't seem to be fixed by your patches. Thanks, Rafael