* Alan Stern [off-list ref] [160202 08:17]:

On Tue, 2 Feb 2016, Ulf Hansson wrote:

quoted

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