On Tuesday, 1 of April 2008, Pavel Machek wrote:
quoted text
> > On Sunday, 30 of March 2008, Rafael J. Wysocki wrote:
> > > On Saturday, 29 of March 2008, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki <rjw@sisk.pl>
> > > > 
> > > > Introduce 'struct pm_ops' and 'struct pm_ext_ops' representing
> > > > suspend and hibernation operations for bus types, device classes and
> > > > device types.
> > > > 
> > > > Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
> > > > objects, if defined, instead of the ->suspend() and ->resume() or,
> > > > respectively, ->suspend_late() and ->resume_early() callbacks that
> > > > will be considered as legacy and gradually phased out.
> > > 
> > > Unfortunately I forgot to set dev->power.status to DPM_PREPARING before
> > > calling ->prepare(), as documented.  Also, dpm_prepare() could cleaned up
> > > a bit.
> > > 
> > > Fixed patch follows.
> > 
> > My testing shows that some drivers tend to return error codes from their
> > ->resume() callbacks, even though the devices in question appear to work
> > correctly after the seemingly failing suspend.
> 
> The drivers should be fixed not to do that, no?

The problem is we generally don't know which drivers do that.  I know a few,
but there probably are others.

So, the idea is to allow them to do that for some time, but log error messages
indicating which drivers they are.  These messages will then allow us to fix
the drivers and once they've been fixed, we can apply a (very simple) patch to
change the behavior of the core (this patch will be easy to revert if need be,
whereas I really wouldn't like to be forced to revert the $subject patch by
predictable regressions).

Thanks,
Rafael
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/