Hi Russ, Russ Dill <russ.dill@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
