From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764134AbdJQUMX (ORCPT ); Tue, 17 Oct 2017 16:12:23 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:36478 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1764050AbdJQUMU (ORCPT ); Tue, 17 Oct 2017 16:12:20 -0400 Date: Tue, 17 Oct 2017 16:12:19 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Ulf Hansson cc: "Rafael J. Wysocki" , Linux PM , Bjorn Helgaas , Greg Kroah-Hartman , LKML , Linux ACPI , Linux PCI , Linux Documentation , Mika Westerberg , Andy Shevchenko , Kevin Hilman , Wolfram Sang , "linux-i2c@vger.kernel.org" , Lee Jones Subject: Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 17 Oct 2017, Ulf Hansson wrote: > > These functions are wrong, however, because they attempt to reuse the > > whole callback *path* instead of just reusing driver callbacks. The > > *only* reason why it all "works" is because there are no middle layer > > callbacks involved in that now. > > > > If you changed them to reuse driver callbacks only today, nothing would break > > AFAICS. > > Yes, it would. > > First, for example, the amba bus is responsible for the amba bus > clock, but relies on drivers to gate/ungate it during system sleep. In > case the amba drivers don't use the pm_runtime_force_suspend|resume(), > it will explicitly have to start manage the clock during system sleep > themselves. Leading to open coding. I think what Rafael has in mind is that the PM core will call the amba bus's ->suspend callback, and that routine will then be able to call the amba driver's runtime_suspend routine directly, if it wants to -- as opposed to going through pm_runtime_force_suspend. However, it's not clear whether this fully answers your concerns. > Second, it will introduce a regression in behavior for all users of > pm_runtime_force_suspend|resume(), especially during system resume as > the driver may then end up resuming the device even in case it isn't > needed. I believe I have explained why, also several times by now - > and that's also how far you could take the i2c designware driver at > this point. > > That said, I assume the second part may be addressed in this series, > if these drivers convert to use the "driver PM flags", right? Presumably. The problem is how to handle things which need to be treated differently for runtime PM vs. system suspend vs. hibernation. If everything filters through a runtime_suspend routine, that doesn't leave any scope for handling the different kinds of PM transitions differently. Instead, we can make the middle layer (i.e., the bus-type callbacks) take care of the varying tasks, and they can directly invoke a driver's runtime-PM callbacks to handle all the common activities. If that's how the middle layer wants to do it. > However, what about the first case? Is some open coding needed or your > think the amba driver can instruct the amba bus via the "driver PM > flags"? PM flags won't directly be able to cover things like disabling clocks. But they could be useful for indicating explicitly whether the code to take care of those things needs to reside at the driver layer or at the bus layer. Alan Stern