From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1 Date: Tue, 2 Feb 2016 08:49:10 -0800 Message-ID: <20160202164910.GV19432@atomide.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from muru.com ([72.249.23.125]:59589 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753415AbcBBQtN (ORCPT ); Tue, 2 Feb 2016 11:49:13 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Alan Stern Cc: Ulf Hansson , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Kevin Hilman , "linux-pm@vger.kernel.org" , Linux OMAP Mailing List , "linux-arm-kernel@lists.infradead.org" * Alan Stern [160202 08:17]: > On Tue, 2 Feb 2016, Ulf Hansson wrote: > > > > Your observations is correct. The hardware will be kept active > > in-between the probe attempts (and thus also if probing fails). > > Although, that's not a regression as that's the behaviour you get from > > runtime PM, when drivers are implemented like omap_hsmmc. > > Perhaps this is what we should do. If probing gets deferred a few > times, doing runtime suspends and resumes in between will be a waste of > time. That sounds like an optimization though. We'd still have to disable the deviec somehow after deferred probe gives up. > ? pm_runtime_put_sync() _already_ does not respect the autosuspend > mode. If you want to respect it, you have to call > pm_runtime_put_sync_autosuspend() instead. I think you found the real bug there. So the right fix is to call pm_runtime_put_sync_autosuspend() at the end of failed probe in omap_hsmmc. Let me give that a try here. Can we add some warning to pm_runtime_put_sync() about that? Regards, Tony