Re: [PATCH v2 1/1] mmc: sdhci-omap: Fix a lockdep warning for PM runtime init

[Tony Lindgren <tony@atomide.com>]

* Ulf Hansson <ulf.hansson@linaro.org> [220623 12:55]:
> On Wed, 22 Jun 2022 at 07:12, Tony Lindgren <tony@atomide.com> wrote:
> >
> > We need runtime PM enabled early in probe before sdhci_setup_host() for
> > sdhci_omap_set_capabilities(). But on the first runtime resume we must
> > not call sdhci_runtime_resume_host() as sdhci_setup_host() has not been
> > called yet. Let's check for an initialized controller like we already do
> > for context restore to fix a lockdep warning.
> 
> Thanks for explaining the background to the problem. However, looking
> a bit closer I am worried that the error path in ->probe() is broken
> too.
> 
> It seems in the error path, at the label "err_rpm_put", there is a
> call to pm_runtime_put_autosuspend(). This doesn't really guarantee
> that the ->runtime_suspend() callback will be invoked, which I guess
> is the assumption, don't you think?

OK I'll check and send a separate patch for that.

> That said, I wonder if it would not be easier to convert the ->probe()
> function to make use of pm_runtime_get_noresume() and
> pm_runtime_set_active() instead. In this way the ->probe() function
> becomes responsible of turning on/off the resources "manually" that it
> requires to probe (and when it fails to probe), while we can keep the
> ->runtime_suspend|resume() callbacks simpler.
> 
> Did that make sense to you?

Simpler would be better :) We need to call pm_runtime_get_sync() at some
point though to enable the parent device hierarchy. Just calling the
sdhci_omap runtime functions is not enough. And we still need to check
for the valid context too. Also I'm not convinced that calling
pm_runtime_get_sync() on the parent device would do the right thing on
old omap3 devices without bigger changes.. But maybe you have some better
ideas that I'm not considering.

Regards,

Tony