* Alan Stern [off-list ref] [160202 10:44]:

On Tue, 2 Feb 2016, Tony Lindgren wrote:

quoted

* Tony Lindgren [off-list ref] [160202 08:50]:

quoted

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

quoted

?  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.

Nope that's not it but getting closer.

The following seems to make things behave for me. Now the
question is.. Does it have some undesired side effects?

Yes, it does.

Yeah noticed..

I'm still not clear on what you want to accomplish.  It sounds like you 
want to perform a runtime suspend following the last probe (if the 
probe fails), and in between probes you don't really care (although it 
would be preferable to avoid suspending).

I'd like to have pm_runtime_put_sync() disable the hardware after
the initial failed probe. Currently that does not happen unless
pm_runtime_dont_use_autosuspend() is called before pm_runtime_put_sync().

Does pm_runtime_use_autosuspend() get called by the probe routine?  If 
it does, then perhaps you can get what you want by having the probe 
routine call pm_runtime_dont_use_autosuspend() whenever it's about to 
return an error -- particularly -EDEFER.

Yes so far that's the only fix that seems to work like I posted
earlier. But is that the right fix though?

If we wanted to have some generic fix, it seems we would have to pass
a new flag in pm_runtime_put_sync() to ignore any autosuspend
configuration. But I don't know if that's what we want to or should
do though?

Regards,

Tony