Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752426AbbKKLD4 (ORCPT ); Wed, 11 Nov 2015 06:03:56 -0500 Received: from mail-yk0-f170.google.com ([209.85.160.170]:35709 "EHLO mail-yk0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751766AbbKKLDx (ORCPT ); Wed, 11 Nov 2015 06:03:53 -0500 MIME-Version: 1.0 In-Reply-To: <2060819.A5Wq9BbBOH@vostro.rjw.lan> References: <87h9kulkfg.wl%kuninori.morimoto.gx@renesas.com> <2060819.A5Wq9BbBOH@vostro.rjw.lan> Date: Wed, 11 Nov 2015 12:03:52 +0100 Message-ID: Subject: Re: [PATCH 2/2] thermal: rcar_thermal: use pm_runtime_put_sync() From: Ulf Hansson To: "Rafael J. Wysocki" Cc: Geert Uytterhoeven , Kuninori Morimoto , Zhang Rui , Eduardo Valentin , Linux-SH , Linux-Kernel , Linux PM list , Cao Minh Hiep , =?UTF-8?B?RHVuZ++8muS6uuOCvQ==?= , Alan Stern Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2525 Lines: 63 On 11 November 2015 at 00:57, Rafael J. Wysocki wrote: > On Tuesday, November 10, 2015 02:00:38 PM Ulf Hansson wrote: >> +Rafael, Alan >> >> On 10 November 2015 at 11:10, Geert Uytterhoeven wrote: >> > Hi Ulf, >> > > > [cut] > >> >> >> >> The problem is that the runtime PM status of the device isn't >> >> correctly updated at ->remove(). The effect is that the the >> >> pm_runtime_get_sync() in ->probe() at re-bind will *not* trigger the >> >> ->runtime_resume() callbacks to be invoked, as the runtime PM core >> >> believes the device is already runtime resumed. >> > >> > So that's where it should be fixed? >> >> That would be a more generic approach, although I am not sure how the >> driver/PM core should be able to take the correct decision in this >> phase. Devices may be runtime PM managed also without a driver bound. >> >> Perhaps when __device_release_driver() finds a bounded driver for the >> device, it could after all actions been performed to unbind the >> driver, check if runtime PM is enabled. If it isn't, it could set the >> runtime PM status to suspended!? >> >> I have no idea if that would introduce other issues as it would kind >> of force the runtime PM status of the device to suspend, without >> actually knowing if it's the correct thing to do. > > IMO, that needs to depend on the bus type. If the bus type has a way > to manage PM for devices without drivers, it should be allowed to do so. By following my suggestion above, we would allow the bus/driver's ->remove() to manage whether runtime PM should be enabled/disabled for the device, before __device_release_driver() checks that. Don't you think that the driver core could rely on that information? I realize that it would be a kind of policy decision for runtime PM, but it's quite similar as when register/unregister devices when we set the runtime PM status to suspended. If you don't think this is a good idea, I guess we need to deal with this from subsystem level code somehow instead. > > Of course, the platform bus type is somewhat special in that respect, > but it looks like we simply need some sort of a convention in there too > (the expectations should be the same for everybody). > > Thanks, > Rafael > Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/