[PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Kevin Hilman]

Hi Russ,

Russ Dill <russ.dill at gmail.com> writes:

[...]

> I was taking a look at this situation, figuring that the
> suspend/resume callbacks in omap_device might be the right place to do
> it, and came across this:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=72bb6f9b51c82c820ddef892455a85b115460904
>
> Under what situations would the driver callbacks be present if probe
> fails? I'm looking at really_probe in drivers/base/dd.c, and if probe
> fails, dev->driver is set to NULL. What was the condition this was
> protecting against?

The static suspend/resume methods for PM domains don't check for
dev->driver.  (c.f. device_resume_noirq()), so during system suspend,
the PM domain callbacks are called whether or not there is a driver.

A simlar fix could've been done by checking for the existence of
dev->driver (and maybe that's a better solution), but I chose the latter
so omap_device has a finer grained track of the driver status.

> Also, by modifying _od_suspend_noirq, can we force idle unbound omap
> device? Would we need a new omap_hwmod flag to check which devices
> should be force idled if no driver is bound?

I suppose you could, but that would probably mask driver bugs where the
driver is not properly runtime suspending itself before being removed.

Kevin