Re: NAK new drivers without proper power management?

On Monday, 12 February 2007 05:08, Nigel Cunningham wrote:
Howdy!

On Mon, 2007-02-12 at 01:10 +0100, Tilman Schmidt wrote:
Hi,

Am 11.02.2007 23:37 schrieb Nigel Cunningham:
On Sun, 2007-02-11 at 00:45 +0100, Tilman Schmidt wrote:
Am 10.02.2007 23:37 schrieb Nigel Cunningham:
If your device requires power management, and you know it requires power
management, why not just implement power management? [...]
Like it or not, power management is far from trivial, and people
writing device drivers have limited resources. [...]
It's not that complex. All we're really talking about is a bit of extra
code to cleanup and configure hardware state; things that the driver
author already knows how to do. S3 might require a bit more
initialisation if firmware needs to be reloaded or more extensive
configuration needs to be done, but if there's firmware to be loaded,
there is a reasonably good probability that we loaded it from Linux to
start with anyway.

You are assuming a perfect world where driver authors have complete
knowledge of their devices. In reality, many drivers (including
those I have the mixed pleasure of maintaining) are based at least
in part on reverse engineering, and managing power states may well
fall into the domain of things not yet sufficiently reverse
engineered.

Nope. I'm assuming that the driver author knows what needs to be done to
get the driver out of whatever state the BIOS puts it in to start with,
and into an operational state, and that they therefore also know what
needs to be done to take it out of the operational state again. I'm
admitting that there's also another state - the post suspend-to-ram
driver state - that they may not know how to deal with. But for
suspend-to-disk, if you know how to get the driver to work in the first
place, you know enough to stop it working (.suspend) and start it up
again (.resume) for the hibernate case at least.

We're talking about _both_ the STR and STD. The drivers that have problems
with the STR cannot be regarded as suspend/resume-safe IMO.

I'm not assuming that you know enough to be able to put the driver into
a low state and get it out again. This is definitely preferable, and at
least possibly essential for suspend to ram, but for some unknown reason
I'm quite hibernation focused, and for that, just the above is
sufficient.

Please take the STR into consideration too. After all we use the same
suspend/resume code for both STD and STR so it should work with both. If it
doesn't work with one of them, we have a problem.

Also, in your argument you neglected a few cases:
- What if my device does not require power management?

Then you as a generic routine that does nothing but return success
(potentially shared with other drivers that are in the same situation).

But if I just write an empty routine like that I open myself up to
criticism along the lines of "writing dummy routines just in order
to shut up kernel warnings". BTDT.

Well, it might not be completely empty. I think someone already pointed
out that there's a minimal workset for the pci bus that pci drivers
would want to invoke. But we wouldn't (rightly) accuse you of such
things if we decided that the policy was "Every driver ought to have a
resume routine, even if it's just a minimal I-just-work route".

I'm still thinking that would be wasteful. I think there are more drivers that
work than there are drivers that don't work.

- What if I don't know whether my device requires power management?

The questions are straight forward: Is there hardware state that needs
to be configured if you've just booted the computer and nothing else has
touched it? If so, that needs to be done in a resume method. Do you need
to clean up state prior to doing the things in the resume method, or
otherwise do things to quiesce the driver? If so, they will need to be
done in the suspend method. The result will be roughly similar to what
you do for module load/unload, except maybe less complete in some cases.

I don't doubt your basic assessment. However it doesn't translate that
easily into a real implementation. In my case, I maintain a USB driver,
so I have to deal with USB specifics of suspend/resume which happen not
to be that well documented. My driver provides an isdn4linux device but
isdn4linux knows nothing about suspend/resume so I am on my own on how
to reconcile the two. The device itself, though in turn far from trivial,
is actually the least of my worries.

Mmm, so that's a case where we need to prod those who write
documentation and bus support first. You're probably closer! :)

Actually, the lack of documentation is a major problem that we all should
try to fix in the first place. Unfortunately the code has been recently
changing quite often, so that's difficult.

Greetings,
Rafael

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

Relevant Pages