Re: [PATCH v2 0/3] PM: runtime: Update behaviour for no callbacks

From: Alan Stern <stern@rowland.harvard.edu>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>,
	linux-pm@vger.kernel.org, Saravana Kannan <saravanak@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Tony Lindgren <tony@atomide.com>,
	Kevin Hilman <khilman@kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/3] PM: runtime: Update behaviour for no callbacks
Date: Tue, 8 Jun 2021 10:24:58 -0400	[thread overview]
Message-ID: <20210608142458.GD1804083@rowland.harvard.edu> (raw)
In-Reply-To: <20210608090250.85256-1-ulf.hansson@linaro.org>

On Tue, Jun 08, 2021 at 11:02:47AM +0200, Ulf Hansson wrote:
> While reviewing a patch on the mmc-list, I ended up inspecting the behaviour of
> how we deal with the no callback case for runtime PM.
> 
> A couple of observations:
> 
> *) When pm_runtime_no_callbacks() have been called, it allows the PM core to
> takes a quicker path, but at the same time, consumer/supplier device links are
> being skipped in rpm_resume|suspend().
> 
> **) Calling pm_runtime_no_callbacks() to avoid boiler plate code (assigning
> empty functions to ->runtime_suspend|resume()), doesn't work if there could be
> consumer/supplier device link being used or a platform dependent PM domain that
> could get attached to the device.
> 
> Therefore, this series suggests to change the behaviour in the PM core, to
> allow the ->runtime_suspend|resume() callbacks to be unassigned. This is already
> supported for ->runtime_idle() callbacks, so it would also move things into a
> more consistent behaviour.
> 
> I have looked at various error paths, in the kernel of callers of
> pm_runtime_get_sync(). I couldn't find anyone that made sense, that looked for
> the special error code, -ENOSYS, which is the error code getting returned when a
> callback is missing. Whether that is sufficient proof that these changes are
> 100% safe, I can't guarantee, but I think it would be worth a try as the
> benefits of avoiding boilerplate code and the corresponding additional code
> paths are quite nice, if you ask me.

In principle I have no objection to these changes.  It's likely 
that if any problems do crop up, we'll be able to fix them pretty 
easily.  For patches 1 and 2:

Acked-by: Alan Stern <stern@rowland.harvard.edu>

Alan Stern

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel