> So you just had to mess it up... Having suspend(device *, state,
> level) might be bad, but having suspend(device *, state, level) in one
> piece of code and {suspend,save}(device *, state) is *way* worse. (And
> I did not see any proposal on l-k. I hope I just missed it).
Calm down, Pavel. From a technical standpoint, it's a superior interface.
Having the 'level' parameter was a mistake made out of speculative
ignorance - we didn't know exactly how the suspend/resume code was going
to work, or exactly what we had to do.
Having explicit calls to save state, power down the device, power on the
deivce and restore state is a Good Thing - it dictates exactly what should
be done at each level. And, it makes more drivers conform to the same
style. Should there be any special cases, then we will deal with them.
Based on the conversations and the code of the last year, those should be
rare.
> So are you going to revert it or convert whole driver model to use
> {suspend,save}(device *, state)?
Today: neither. I'm going to see how this works, and if it does, then I
may convert all the users of struct device_driver to use the same model.
The interfaces are obvious, and they are documented in the changesets, as
well as the code. Soon, they will be documented in text files shipped with
the kernel. I have complete confidence that anyone that takes the time to
become versed enough in current power management semantics will have no
problem with the new methods for system devices.
-pat
-
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/
This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:29 EST