Re: Subtle semantic issue with sleep callbacks in drivers

[Pavel Machek <pavel@ucw.cz>]

Hi!

> - On any machine, with suspend to disk, the slot is powered off (along
> with the entire host machine). But the machine will be rebooted and the
> device put back to "idle" state some way by the loader kernel, so this
> ends up a bit like the above case.

Actually as swsusp gets better it should power the device off then
on... OTOH that is very hard for video cards.

> So basically, the "state" parameter should encore not only what state
> we want to go to, but rather, what will happen to the slot:
> 
> - Nothing (it's entirely up to the driver to do it's own power
> management, that happens for some devices inside Apple ASIC), though in
> this case at least, those driver have control over the chip power, reset
> lines, etc...
> - Slot will be unclocked (it's up to the driver, it the chip supports
> static mode, to go to D2 or D3 if the driver can deal with it, though
> the system will do nothing to help the driver)
> - Slot will be powered off. This case should be broken up (via an
> additional flag passed to the driver ?) into 1) the system _will_
> re-POST the card before resume (BIOS/ACPI support, swsusp) or the
> system will NOT re-POST the card, the driver shall fail the sleep
> request if it can't do it by itself.

This is also possibility. Yes, this is probably good idea for at least
short term. Then we should make sure that "will re-post" is used less
and less and that it finally disappears.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]